ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<andrewrk> gitlab won't let me fix having 2 accounts that should have been the same one
<daurnimator> I'm missing context to understand your statement.
<andrewrk> I'm annoyed that I have 2 accounts on gitlab and it won't let me merge them into one
kristoff_it has joined #zig
<andrewrk> um... no:
<andrewrk> I'll try to set it up without that authorization
kristoff_it has quit [Ping timeout: 245 seconds]
<daurnimator> andrewrk: "This project integration is separate from the instance wide GitHub integration and is automatically configured on GitHub import."
dazhbog has quit [Ping timeout: 260 seconds]
<hryx> damn, that's a lot of permissions. such a tragic thing about OAuth apps. I really wish apps could ask for permissions as needed/desired, per integration feature
darithorn has quit [Quit: Leaving]
<NI33_> andrewrk: If i am not mistaken, when you want to integrate to accounts (and continue to use a non-paid membership) you need to do something very old fashioned, namely send an e-mail and ask them to integrate your accounts (i could be mistaken, but i do think i ran into the same issue a while ago, and just gave up, seeing that)
<NI33_> *to=two
<NI33_> If the gitlab service was just a little older, i am sure you would have had to send them a letter via PO-BOX 372834 :-)
<NI33_> (Note: It might have been some other REPO/CI service that had this, and i am mistaking it for gitlab)
<NI33_> Please discard my message above. Did a little digging and it was SemaphoreCI requiring me to e-mail them. Sorry about that.
reductum has quit [Quit: WeeChat 2.5]
<mikdusan> daurnimator: awesome. you got that arm account!
<daurnimator> mikdusan: yep
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
ltriant_ has joined #zig
ltriant has quit [Ping timeout: 258 seconds]
return0e has quit [Ping timeout: 248 seconds]
iamthad has quit [Quit: ZNC -]
laaron has joined #zig
darithorn has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<daurnimator> emekankurumeh[m]: there?
laaron- has joined #zig
laaron has quit [Quit: ZNC 1.7.1 -]
a_chou has joined #zig
kristoff_it has joined #zig
a_chou has quit [Quit: a_chou]
kristoff_it has quit [Ping timeout: 245 seconds]
darithorn has quit [Quit: Leaving]
jmiven has quit [Ping timeout: 246 seconds]
wilsonk_ has quit [Ping timeout: 246 seconds]
wilsonk_ has joined #zig
jmiven has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
ltriant_ has quit [Ping timeout: 245 seconds]
ltriant has joined #zig
kristoff_it has joined #zig
ltriant has quit [Quit: leaving]
laaron- has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
kristoff_it has joined #zig
return0e has joined #zig
laaron has quit [Remote host closed the connection]
st4ll1 has joined #zig
noonien has quit [Quit: Connection closed for inactivity]
marmotini_ has joined #zig
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
FireFox317 has joined #zig
<FireFox317> andrewrk: Regarding the `pub extern` issue, should we mark all the exported functions as `pub` internally in the compiler?
<FireFox317> *export
FireFox317 has quit [Remote host closed the connection]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
halosghost has joined #zig
SimonN has quit [Remote host closed the connection]
Poetastrophe has joined #zig
<Poetastrophe> Hey guys! I am using std.debug.c_allocator in a small project and I can't seem to link against libc. I tried to specify it in the build.zig like so:
<Poetastrophe> But when I build and then run I get:
<Poetastrophe> As if I haven't specified it
bheads has quit [Ping timeout: 272 seconds]
Poetastrophe has quit [Remote host closed the connection]
bheads has joined #zig
st4ll1 has quit [Ping timeout: 245 seconds]
st4ll1 has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<fengb> "zig run" doesn't actually use the build file
<companion_cube> why not?
<fengb> You'll need to enable "zig build run" manually, like this
<fengb> Only "zig build [x]" uses the build file
<fengb> Other commands just invoke the compiler directly
laaron has quit [Remote host closed the connection]
<fengb> Oh that's an old reference. Lemme find a more recent one
laaron has joined #zig
<fengb> Oh wait, you added the run step already. Just do "zig build run"
Poetastrophe has joined #zig
<Poetastrophe> Ahh I see fengb, thanks!
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<mq32> mikdusan, i just read your "inhertance & interfaces" proposal
<mq32> sounds pretty good already :)
<mq32> do you have an idea how interface references are stored?
<Poetastrophe> Though fengb it produces FileNotFound (seems to have trouble finding the executable). Cannot really deduce why it would do so:
<mikdusan> mq32: tbh i am not sure of those details yet; want to hash out what can be hashed out before those details
<mikdusan> mq32: i admit there is more to add about interfaces since revising the proposal. i must be more clear. working on that.
<fengb> Poetastrophe: I’ve been getting that error too. I think it’s a recent bug
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
<Poetastrophe> fengb aight that's unfortunate
<bheads> What happened to the comptime type checking proposal?
<scientes> bheads, ??? types are checked at comptime
<bheads> pub fn quack(duck: var<meta.is_a_duck()) void { ... }
<bheads> pub fn quack(duck: var<meta.is_a_duck>) void { ... } **
<scientes> just put it in your function
<bheads> you want the compiler to reject the call site
<scientes> if (@typeOf( @compileError()....
<bheads> not the function
<scientes> its still comptime
<bheads> call site
<scientes> then use another function
<scientes> with differn't requirements
<bheads> then we dont need inheritance
<scientes> i don't see the problem
<bheads> I was responding to the new inheritance proposal
<scientes> yeah , i'd rather not have inheritance
<bheads> exactly
<scientes> @fieldParentPtr is sufficient
<scientes> once it is fixed
<fengb> That’s more “traits” than inheritance
<bheads> @fieldParentPtr is messy
<scientes> it just has to be fixed
<scientes> its still beautiful
<fengb> Yeah I don’t really want inheritance either
<scientes> OO is best used sparingly
<bheads> the idea was to make "traits" cleaner
<bheads> with the trait in the signature not in the body
<mq32> mikdusan, i hope i get some time later to write a response to your proposal. i have some more specific ideas and commets
st4ll1 has quit [Ping timeout: 268 seconds]
<bheads> easier to debug that: quack(a_dog); is the error then if ( std.meta.hasFn(duck, some long fn signature)) ...... in duck.quack ...
st4ll1 has joined #zig
<mikdusan> mq32: would love to hear them
<daurnimator> bheads: hrm. I can't find it now, but theres a comment around that proposes you can provide a function as a type and it would get called to check if it was valid
<bheads> I think that pattern would cleanup things like the Allocator and Iterator patterns
<bheads> even cleaner would be to define the trait as a type
<bheads> const Allocator: type = var<std.mem.is_allocator>;
<daurnimator> mikdusan: ah ha, thanks
<mikdusan> that proposal is sneaky powerful.
<bheads> yeah thats it!
<bheads> yeah it would solve a lot of these kind of issues
<scientes> wut
<bheads> and we wouldnt need @fieldParentPtr as much
<scientes> we still need it
<scientes> it is performant
<bheads> sure but not as much
<scientes> (once it is fixed to not interfere with other things)
* scientes still likes @fieldParentPtr
<scientes> there was a issue to make it only callable on types that declare support for it
<scientes> which fixes the strict aliasing issues
<scientes> and makes it less of a foot-gun
darithorn has joined #zig
<bheads> lol scientes, I dont think its going anywhere
<daurnimator> @fieldParentPtr needs 'nocopy'/'fixed' to be less of a footgun
<daurnimator> I recall andrewrk saying it was the number 1 mistake by new zig programmers. it sure was for me.
<daurnimator> > I agree that this is a big flaw in the language. It's a top priority to fix in 0.4.0.
<scientes> the impossibility of @fieldParentPtr was one of the reasons I stopped trying to learn go
kristoff_it has quit [Ping timeout: 244 seconds]
<fengb> It’s also hostile to optimization
<scientes> which optimizations?
<scientes> I only see strict aliasing (which isn't a zig thing right now)
<scientes> cause its just an addition/subtraction
<scientes> oh yeah now i remember
<scientes> well, anyways, my use-case for fieldparentptr is for data structures (like my rb.zig), where it is just a add/sub
<daurnimator> I use it for e.g. intrusive linked-list nodes
<scientes> I should look at the code
<scientes> cause I wrote something similar
<scientes> and then never polished it
<scientes> but yeah, that is what "intrusive" means
<scientes> how do i turn off the segfault handler?
<mikdusan> try adding `const enable_segfault_handler = false;` to @root ?
<daurnimator> mikdusan: yep that should do it.
<scientes> @import("root")
<scientes> oh nvm
kristoff_it has joined #zig
Poetastrophe has quit [Remote host closed the connection]
Akuli has joined #zig
bheads_ has joined #zig
bheads has quit [Ping timeout: 244 seconds]
bheads has joined #zig
bheads_ has quit [Ping timeout: 258 seconds]
laaron- has joined #zig
laaron has quit [Quit: ZNC 1.7.1 -]
laaron- has quit [Remote host closed the connection]
Poetastrophe has joined #zig
<Poetastrophe> I tried to make an ordered_map datastructure (which should have a identical interface as the buf_map) using the rb.zig library. But I seem to be getting a dangling pointer. The implementation is under 100 lines: And I get the following error
<Poetastrophe> e/84d5fd3441139f98936f177d2dab65a5 . Any help would be much appreciated
Poetastrophe has quit [Remote host closed the connection]
<euantor> Gist URL from above seems to have been cut off:
marmotini_ has quit [Quit: Leaving]
Poetastrophe has joined #zig
Poetastrophe has quit [Remote host closed the connection]
kristoff_it has quit [Ping timeout: 246 seconds]
dimenus has joined #zig
<dimenus> andrewrk: do you have anything written up on error return traces vs exceptions?
<dimenus> just curious
<dimenus> is it just simpler in zig because we don't have constructors/destructors?
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
gokr has joined #zig
<emekankurumeh[m]> daurnimator: thanks!
<emekankurumeh[m]> andrewrk: I'm working on adding a ci job for mingw-w64, what would it take to get it added to the downloads page?
<andrewrk> emekankurumeh[m], in theory is it possible for the windows download to be appropriate for mingw-w64 as well as native windows?
<andrewrk> or is there some reason the builds have to be different?
<andrewrk> dimenus, the only thing I've written up is
<emekankurumeh[m]> mostly it just makes things nicer as the binary front the downloads page assumes the c ABI as msvc even on gnu
<dimenus> mingw64 does use the msvc abi
<emekankurumeh[m]> i suppose we could just add runtime detection for the c ABI
<dimenus> it's meant to interop without any extra dlls
<dimenus> unlike cygwin
<emekankurumeh[m]> by c ABI I mean the libc (basically)
<dimenus> ah
<dimenus> yeah in that case they have their own wrappers for certain things
<emekankurumeh[m]> as that's how zig refers to it in the triple
<andrewrk> emekankurumeh[m], perhaps we can improve native ABI detection. are there are environment variables or something that mingw-w64 provides?
<dimenus> i'm making good progress with Vulkan
<dimenus> other than the occasional hand edits of the translated c, it's been pretty easy to use with Zig
<dimenus> environment variables or #defines?
<andrewrk> dimenus, we're talking about an executable at runtime detecting that the native ABI should be mingw
<emekankurumeh[m]> sure, I think we already do something like that by checking if certain pipe handles exist
jjido has joined #zig
<emekankurumeh[m]> but also using lld with mingw-w64 is faster that msvc and cl
<dimenus> i haven't experienced that except on a first build
<emekankurumeh[m]> I'd rather not make the windows ci job any longer
<dimenus> cl has incremental linking
<dimenus> er link does
<dimenus> i'm not sure I understand why you guys keep referring to this as 'ABI' though other than the target triple being kind of misleading
<dimenus> the calling conventions of mingw compiled applications are the same as that of native MSVC compiled applications
<emekankurumeh[m]> really? maybe we should take advantage of pipeline caching
<dimenus> on msys2/cygin that's a different story
<dimenus> those programs literally won't load / link with the msvc toolchain
<dimenus> *cygwin
<emekankurumeh[m]> in the target triple when targeting mingw the ABI we pass is gnu, there is no difference but llvm pretends there is so we do too
<andrewrk> dimenus, yes they have ABI compatibility but there are still differences in the target
<emekankurumeh[m]> msys2 isn't cygwin
<dimenus> i didn't say they were
<andrewrk> the linker acts quite differently for the mingw abi vs msvc
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dimenus> msys-2.0.dll and cygwin.dll both provide a posix translation layer
<dimenus> agreed
<andrewrk> we might even want to have std.fs.path.sep be `/` rather than `\` for windows-gnu target
<emekankurumeh[m]> yes please
<andrewrk> let's do it
<dimenus> i don't think that's right
<dimenus> msys-2.0 is not linked into mingw64 programs
<dimenus> only msys programs
<emekankurumeh[m]> though all of zig works with / instead of \ except for zig fmt
<emekankurumeh[m]> oh, that explains what you mean
<dimenus> i'm just trying to make sure we're differentiating between msys2/cygwin (which do provide posix translation)
<dimenus> and mingw64
<dimenus> which is a regular windows binary
<dimenus> if you don't link in libc on mingw64, i'd be curious to see if the path actually gets translated
<dimenus> my guess is that it will not
<emekankurumeh[m]> translated?
<emekankurumeh[m]> I can't wait for @result, the result variable was something i really liked in nim
<emekankurumeh[m]> i'll make a pr for this stuff
<scientes> emekankurumeh[m], but why, just have a differn't variable, and then return it?
<emekankurumeh[m]> copy elision, plus i don't like just declaring the variable just to return it, @result feels a lot cleaner imo
batok has joined #zig
<scientes> I think copy elision can just be done with static analysis
<scientes> and I'd rather avoid an extra feature in the language
<gokr> Hi all, I am new to Zig since... 24h, but find it interesting. Was wondering, anyone here with experience in Nim that can ... contrast Zig with Nim? I have done a fair bit of Nim.
<andrewrk> zig has fewer features than nim, compiles directly to machine code (not C), and emphasizes cross compilation
<gokr> Those parts I already got ;)
<halosghost> zig also emphasizes safety and predictability
<gokr> Although there is also an experimental LLVM backend for Nim, though... not primary work there AFAIK
kristoff_it has joined #zig
batok has quit []
<gonz_> Hang on, what's this about `@result`?
<halosghost> nim, in large part because it compiles to C, still has quite a bit of undefined behavior
<andrewrk> dimenus, I see your point. Yes I think we would only want `/` instead of `\` if it was msys2/cygwin
<andrewrk> halosghost, I'm not sure that's correct, be careful accusing another language of that
<dimenus> agreed
<andrewrk> it's pretty easy to avoid the undefined behavior of C when using it as the output of a compiler
<gokr> I made Spry ( in Nim and also used it together with Urho3D in my old job etc. It's a beast, but... strangely practical also. Regarding the "undefined behavior" - I have heard that being brought forward lots f times, especially from Rusters - but... it feels largely theoretical.
<halosghost> andrewrk: it has been a while since I've looked into nim, but the last time I did, it had made some decisions such as defaulting all integers to signed integers and not providing unsigned integers; and, at least at the time, it didn't do anything to catch/prevent overflow
<andrewrk> halosghost, that's a fair criticism, but that's unrelated to C having undefined behavior - see what I mean?
<halosghost> mm
batok has joined #zig
<gonz_> gokr: zig emphasizes compile-time evaluation of normal code in contrast to Nim and many other languages.
<gokr> "in contrast to nim"?
<halosghost> I suppose, though I think claiming that it isn't related to C's UB is actually more of an assertion about the language authors than I had made
<andrewrk> gokr, you might enjoy this talk I gave recently:
<halosghost> andrewrk: I suppose I was trying to offer the benefit of the doubt to the nim authors that they just had to bite that UB because C has it; suggesting that they should do otherwise is an assertion that they made a poor choice
<halosghost> which is not necessarily incorrect
<gokr> Compile time evaluation is exactly what Nim also can do.
<gonz_> gokr: Correct me if I'm wrong, but does Nim not emphasize macros as opposed to just compile time evaluation?
kristoff_it has quit [Ping timeout: 272 seconds]
<halosghost> but, it was my hope by my phrasing explicitly to not indict them
<halosghost> it seems like I failed in that, so my apologies
<gokr> andrewrk: I actually watched that (although speed flipping)
<andrewrk> halosghost, I think a fair way to put it would be that you disagree with the design decisions about integers
<halosghost> andrewrk: fair enough
<halosghost> oh, I can say this
<halosghost> afaik, nim doesn't have arbitrarily-sized, fixed-width integers and zig does
<halosghost> which, I think, should award 2^252 (one for each extra integer type that zig supports) points to zig :P
<gokr> gonz_: Eh.... Nim has a macro system that operates on the AST level, and it does so by using Nim. In fact, Andreas even wrote a Nim interpreter mainly to be used during compilation.
<gonz_> gokr: Note that AST manipulation is different than what zig does. zig does not try to give you a macro system.
<halosghost> (seriously, it's one of my favorite things about zig; which I know is a little silly)
<gokr> gonz_: I know Zig doesn't do AST manipulation, but.... Nim also runs Nim during compile time.
<andrewrk> that's neat, I didn't know nim had that
<gonz_> Having used many macro systems I can tell you zig is a different idea than all of them.
<gonz_> I suggest you make use of it.
<gokr> For example you can write a const proc that produces a CRC table, and have it run at compile time. It may even be more advanced than Zig in this arena- though I am not sure about Zig's limitations.
<gonz_> Yes, it *is* more advanced, that's part of the point.
<batok> Is there a source code example about a tcp server or client?
<gonz_> zig is a much smaller idea with much more bang for your buck than any macro system.
<andrewrk> does nim let you do any of these during compile time code execution? inline assembly, external function calls, syscalls
<andrewrk> batok, yes but that's a bit under construction for the moment. I suggest using C libraries for that (or libc) or waiting a couple months
<gokr> andrewrk: Unsure about the limitations, the const stuff is meant to be deterministic - so there such stuff is "forbidden" of course.
<andrewrk> batok, I'm working on async/await right now, and next up after that is event-based networking API in the std lib
<batok> ok i will wait tks
<gokr> andrewrk: But nimscript is also based on the same interpreter - and it can do quite a lot of such stuff (since it's used to make "portable shell scripts" etc)
<andrewrk> gokr, sounds like nim & zig made the same decision then and the features should be roughly equivalent
<gonz_> gokr: I don't think soliciting responses about differences and mounting defenses about the responses is going to net you more than sitting down and writing some zig. It's a very small, simple language and you can pick it up very fast.
<gokr> I am a Smalltalker at heart so... I am used to "blurring" runtime and compile time ;)
<gonz_> Having written production code in Racket and Elixir I can tell you that there is a qualitative difference between the kind of compile-time features you get in zig and macro systems.
<gokr> gonz_: I am not mounting defenses - I am trying to find the ... major differences.
<gonz_> You're not going to theorize your way to this, I don't think
<gokr> Probably not, I know. Was just hoping to find some people knowing both.
<batok> can nim compile to wasm these days?
jjido has joined #zig
<gokr> gonz_: So you think Zig goes further towards Lisp/Smalltalk etc?
<andrewrk> gonz_, I think your suggestions are reasonable, but let's try to have a welcoming attitude to the newcomers :)
<gonz_> batok: If it compiles to C it can
<gokr> andrewrk: I am cool, no problem. I may sound as one of those coming to "argue" - but... I am a sucker for languages simply.
<andrewrk> I agree with gonz_ though that the best way to find out is to try it out
<strmpnk> I'd call zig more of a staged compilation setup for metaprogramming, which is really different from macro based metaprogramming. Staging isn't as common as AST based metaprogramming but has a lot of advantages with uniformity of language when moving concepts between the two layers...
<gonz_> gokr: zig is much more limited in what it exposes as an interface for compile-time stuff. The compile-time stuff you write is exactly what you would have for non-compile-time. Pound for pound it's very valuable but as with everything in zig it's intentionally simple.
<strmpnk> It's a lot easier to lift into or out of comptime than switch an AST manipulation into straight-line code.
<gonz_> strmpnk: Right? Precisely because it's just zig code and the only thing you really need to consider are the stage requirements.
<strmpnk> Yes. Constraints like comptime are very expressive IF given good reflection, which Zig has done a good job with.
<gokr> Yeah, sounds reasonable. Loved the way generics works in Zig btw.
<gokr> As a Smalltalker I love it when things are reified :)
<gonz_> Exactly, and that's part of what makes it such a pound for pound good feature
<gokr> Spry is about .. 2.5k Nim code, I was thinking of porting over to Dart (I work a lot in Dart these days) - but... Zig is tempting.
<andrewrk> zig is still immature, lots of bugs, beta software, but if you're cool with that then it would be a great fit
andersfr has joined #zig
<gokr> I do however rely quite a bit on runtime polymorphism (Nim methods) - is the answer in Zig country.... tagged unions?
<gonz_> gokr: Do you work at a big dart shop? This sounds interesting.
<gokr> No, I work at a company making... robot gloves ;)
<gokr> Anyway, I decided to go "all Dart" there for both server side and mobile apps etc.
<gokr> Has worked really well so far.
<andrewrk> gokr, tagged unions work well (even untagged unions have runtime safety with a secret tag field) but if you want runtime polymorphism, the current solution is to roll your own using @fieldParentPtr. the relevant issue to track is
<gokr> Ah, super. Thanks
<fengb> andrewrk: I’ve been getting a weird error in master:
<fengb> Should I create an issue?
<gonz_> `@fieldParentPtr` is a bit controversial, though, it should be said?
<gokr> Spry is... just a trivial little AST interpreter - but a fun little experiment. I also noted you mentioned doing "stackless" parsing somewhere - in fact exactly what I wanted to do in Spry next (it's currently just a silly recursive interpreter).
<andrewrk> fengb, looks like the install step is not doing mkdir -p and that's causing the error
<andrewrk> fengb, an issue would be appreciated
<andrewrk> gonz_, I'd say @fieldParentPtr as *the solution to runtime polymorphism* is controversial
<gonz_> Right, yes
<fengb> Ah if it’s the install step, I think I can take care of that
<andrewrk> but that's why #130 is still open
kristoff_it has joined #zig
<andrewrk> fengb, yeah. I think what's confusing about that error return trace is that one of those errors was handled, but then ultimately the call still errored out
<gonz_> gokr: Did pure function annotations land in Nim yet?
<andersfr> andrewrk: I made a context-free LALR parser of Zig. I had my doubts at first but it was indeed possible
<andrewrk> but that actually gives you more information if you think about it
<gonz_> gokr: Ah, found it in the manual.
<andrewrk> andersfr, interesting! I would be interested in engaging with you more on this once the syntax is stabilized - as it is more changes are planned (specifically with regards to async/await and a couple other things)
<gokr> andrewrk: Not sure if it is of interest - but async/await in Nim was made purely with macros actually.
kristoff_it has quit [Ping timeout: 258 seconds]
<andrewrk> gokr, that's neat. is it based on stackless coroutines / CPS?
<andrewrk> does it work with a thread-pool based event loop?
<gokr> Extremely good question - have no idea :)
<gokr> But it was dom96 who wrote it IIRC
<gokr> He is on IRC
<gonz_> What's this about `@result`, by the way? Is there an issue to look at? GitHub search taunts me as usual.
<gokr> He also wrote the Nim book and lots of the web stuff in Nim etc. Very nice guy
Akuli has quit [Quit: Leaving]
<andersfr> andrewrk, you can find the implementation at
man213 has joined #zig
andersfr has quit [Remote host closed the connection]
andersfr has joined #zig
<emekankurumeh[m]> andrewrk: it is based on iterators
<emekankurumeh[m]> I do think they use a threadpool under the hood for it
<emekankurumeh[m]> here is a link to a talk in how their async is implemented: it's a bit old though
marijnfs has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Sahnvour> if I get this right, it's planned to have a thread pool tightly coupled with the async/await feature ?
<andrewrk> Sahnvour, not tightly coupleid
<Sahnvour> relieved
Ichorio has joined #zig
<andrewrk> async/await is lock-free and atomic, which means that it is compatible with a thread pool event loop implementation in the standard library
<andrewrk> there's already a proof of concept of this (albeit with the async/await semantics that I'm currently reworking)
<dimenus> how would i discard only a specific type of error?
<Sahnvour> I fail to see where the delimitation between language support (`await`) and library support (thread pool) is, feels abstract to me for now
kristoff_it has joined #zig
<dimenus> _ = try std.fs.deleteFile(full_out) catch error.FileNotFound;
<dimenus> i just want to delete a file if it exists
<fengb> async/await only denotes runtime semantics. It could theoretically be backed by any execution strategy, of which thread pool is one (and event loop would be another)
<nrdmn> feature request: bitwise assignment operators (^=, &= etc.) for bool
bheads has quit [Ping timeout: 244 seconds]
<andrewrk> dimenus, switch on the error, handle the one error, and then `else => |e| return e,`
kristoff_it has quit [Ping timeout: 245 seconds]
<dimenus> ah i was missing the second capture
<halosghost> nrdmn: at least one other person here (scientes iirc) is planning on PR'ing that iirc
<andrewrk> dimenus, the captured error set in the else will omit the ones you handled
<nrdmn> alright
jjido has joined #zig
<halosghost> hmm, I might be wrong about that
andersfr has quit []
<Sahnvour> fengb: and is an event loop something more than just a thread pool with only 1 thread, conceptually ?
<dimenus> maybe this doesn't work in build.zig
<dimenus> i'm not even seeing my function call
<andrewrk> dimenus, I'm not sure what you're saying - build.zig is just zig code. you can read the full source of the main() entry point here:
<scientes> halosghost, nrdmn it would help if someone wrote up a proposal
<scientes> I have the code somewhere and it works
<dimenus> andrewrk: sorry for the false alarm, there's just a big in my zig code
<dimenus> *bug
<dimenus> i was trying to copy the *.spv files before the systemCommand actually ran
<fengb> Sahnvour: I suppose it can be modelled as an infinite loop against 1 thread. I'm not sure how OSs or node.js does it internally
ofelas has joined #zig
<dimenus> essentially i'm just trying to copy shaders/*foo.spv to my bin directory
<dimenus> but the system command hasn't run yet
<andrewrk> dimenus, ah yes one thing to remember is that build.zig is declarative
<andrewrk> it'll become more clear why that is in the future
<dimenus> sorry i'm being obtuse, i don't know what you mean by that
<dimenus> i can just move the copy to later in the process
<andrewrk> once your build() function completes, nothing is actually done yet. build() only creates a graph of build steps
<andrewrk> that's why, for example, `zig build --help` contains the options and user-defined steps
<Tetralux> (The build fn is basically just the system asking you what you want - and then after it returns it then goes and actually does it all.)
<dimenus> ok, so i have a very similar setup to your vulkan example
<dimenus> accept I'm also copying the shaders to the output bin directory
<dimenus> *except
<andrewrk> dimenus, for your compiled shaders I recommend using the install functions, and then finding them at runtime based on the installation path, or relative to the binary path
<andrewrk> or `@embedFile` at build time
<dimenus> i am using installBinFile, the problem is the compiled shader isn't built yet
<dimenus> or do i just need an extra step?
<andrewrk> you probably just need to declare a step dependency
<andrewrk> b.getInstallStep().dependOn(the_step_that_compiles_the_shaders)
<andrewrk> I should update the vulkan example to do this
<dimenus> that was it
<dimenus> just need to have the install step depend on the compilation step (rather than the exe compilation)
<dimenus> can the install step depend on both?
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dimenus> nvm, i'm good to go. thanks andrewrk/Tetralux
<Tetralux> dimenus: o7
<andrewrk> dimenus, at some point here the API will be improved so that zig build does caching on system commands if you go through the trouble to specify all the inputs and outputs
<andrewrk> this will also make it easier to make the API friendlier with regards to step dependencies
wootehfoot has joined #zig
huffmanr has joined #zig
marijnfs has quit [Ping timeout: 252 seconds]
marijnfs has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<dimenus> on to an obj loader!
<andrewrk> neat
jjido has joined #zig
halosghost has quit [Quit: WeeChat 2.5]
huffmanr has quit [Remote host closed the connection]
st4ll1 has quit [Ping timeout: 248 seconds]
st4ll1 has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
marijnfs has quit [Ping timeout: 246 seconds]
Ichorio has quit [Ping timeout: 264 seconds]
jjido has joined #zig
jjido has quit [Client Quit]
<scientes> dimenus, are you writing a dynamic loader?
<andrewrk> scientes, I believe obj in this context is a mesh (for 3d graphics)
<scientes> oh cool
<scientes> dimenus, if you need some specific SIMD thing let me know
man213 has quit [Quit: Going offline, see ya! (]
<dimenus> yes, that is correct (mesh loader)
<dimenus> i have a working 3d scene w/ depth buffer in vulkan
<dimenus> and now i need meshes
<scientes> oh, yeah yulkan does its own SIMD/shader compilation
<scientes> although it actually uses llvm to do it........
<dimenus> amd wrote another shader compiler
<dimenus> i haven't tinkered with it yet though
<dimenus> scientes: I have a local branch with shawnl's vector specific enhancements
<dimenus> it's worked out well so far
<scientes> dimenus, type /whois scietes
<dimenus> ah :D
<dimenus> scientes: i don't have a link to the specific thread in the llvm mailing list, but they were looking at removing the experimental tag from hadd/hmul
<dimenus> hadd would be nice for matrix operations
<nrdmn> what's the correct way to write a C void pointer? *c_void, [*c]c_void or something else?
<scientes> dimenus, no problem with adding it, but we need a syntax
<scientes> I guess I could just add builtins and think about that later
<scientes> oh yeah you def. need it
<scientes> did you even check if llvm optimizes those?
<dimenus> it doesn't
<dimenus> well they're already in xmm registers
<dimenus> but the adds are one at at time
<dimenus> the muls work great
<dimenus> *regular muls
<scientes> but that could be a vector mul
<dimenus> it is a vector mul, sorry by regular i meant component wise
<dimenus> rather than horizontal
<scientes> just use @splat on the vector eement
<fengb> nrdmn: c_void or []c_void. [*c] means you don’t know whether it’s an array or singular pointer and generally be used only by translate-c
<dimenus> huh?
<scientes> this could be lhs.vecs * @splat(4, rhs.vecs[0])
<dimenus> why do i need splat there?
<dimenus> that's a vector / vector mul
<scientes> to turn 4 lines into one
<scientes> ohhhh
<nrdmn> In zig's source code there's plenty of *c_void and one [*]c_void
<nrdmn> fengb: c_void is a void. I want a void pointer.
<fengb> Yeah, I just mean you shouldn’t need to type [*c]
<nrdmn> []c_void is a slice of c_voids, I think (?)
<andrewrk> nrdmn, if you can, try to make an @OpaqueType() specifically for the underlying type. if you need a globally opaque type, consider using the pointer address (usize)
<fengb> In zig we distinguish singular pointer, c_void is a pointer to an item, and array pointer, []c_void is a pointer to an array of items
<fengb> Slice is not ABI compatible with C
<nrdmn> fengb: according to the documentation c_void is a void, not a *void
<fengb> I think my asterisks are disappearing in this app
<fengb> Ugh..
<fengb> Sorry those lines were supposed to have asterisks
<nrdmn> :D alright
<fengb> *c_void is a pointer to an item, and array pointer, [*]c_void is a pointer to an array of items
<fengb> Okay I have extra text now... but hopefully that’s parseable
<fengb> Both translate into *void in C but they carry a little bit of semantic meaning in Zig
<ofelas> i'm getting some weird errors with File.openRead,
<scientes> oh what a load of bollucks
<scientes> C++......
<scientes> if you type cast something it does differentiate it on type signatures
<scientes> what a great language
<scientes> *typedef
<mikdusan> it needs a new feature: ACINAE - ambiguous cast is not an error
<scientes> nice sarcasm
<nrdmn> andrewrk: what is a 'globally opaque type'?
<scientes> nrdmn, it means sizeof is not known
<scientes> we need it because C has it
<fengb> C can export a struct pointer but never defines the struct. That sort of thing
ltriant has joined #zig
SimonNa has joined #zig
kristoff_it has joined #zig
ntgg has joined #zig
kristoff_it has quit [Ping timeout: 244 seconds]
uso_ has quit [Ping timeout: 252 seconds]
kristoff_it has joined #zig
ltriant has quit [Ping timeout: 245 seconds]
kristoff_it has quit [Ping timeout: 272 seconds]
ltriant has joined #zig
gokr has quit [Ping timeout: 258 seconds]
<nrdmn> in std/fs/file.zig there are `const`s in a struct. It doesn't seem to be documented that this is possible
* gonz_ ```
<nrdmn> oh right
<nrdmn> thanks
<gonz_> NP :)
<gonz_> Super hard to find stuff atm