ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<gpanders> posixlix: what is the type of val.tag in this example? a string?
<posixlix> std.meta.Tag(Foo_Union), I guess.
<zags> ikskuh: so that's interesting. I do var x = allocator.create(MyThing), then later do allocator.destroy(self). I log that it happens. Still, std.testing.allocator claims that the create call causes a leak.
marijnfs has quit [Quit: WeeChat 2.8]
zags has quit [Ping timeout: 240 seconds]
gazler__ has joined #zig
gazler_ has quit [Ping timeout: 240 seconds]
brzg has joined #zig
cole-h has quit [Ping timeout: 240 seconds]
earnestly has quit [Ping timeout: 265 seconds]
brzg has quit [Quit: leaving]
pyrmont has joined #zig
ky0ko has joined #zig
<pyrmont> Hi, I'm very new to Zig and am currently going through ziglearn.org. A few times in chapter 1 it mentions coercion. I'm a little confused what it means when it says, for example, '*T coerces to [*]T' (https://ziglearn.org/chapter-1/#multi-pointers). I think I follow 'coerce' when it's used as a transitive verb, but what does it mean to say that something 'coerces' in an intransitive sense?
<andrewrk> to be clear, *T does not coerce to [*]T
<andrewrk> there is an open proposal for that, I believe
<pyrmont> Oh.
<andrewrk> you can think of coercion like this: does zig let you do this? const x: T = y;
<andrewrk> if yes, then y coerces to x.
<pyrmont> Ahhh.
<pyrmont> Great—thanks :) That helps a lot.
bitmapper has quit [Quit: Connection closed for inactivity]
<squeek502> g-w1, how would stage2 emit an exe even when encountering a compile error?
<squeek502> am i missing something?
<g-w1> the errors for @compileLog are special
<squeek502> imo compilation succeeding with compile errors seems like a bug
<squeek502> are compileLog errors meant to be special in that way?
<g-w1> it will still produce the stub of a binary even with a blatant error
<g-w1> (let me link to a discussion i had about this a while ago on irc)
<squeek502> where is the emit happening in that branch?
<g-w1> compilation.update() ?
xackus has quit [Ping timeout: 265 seconds]
<g-w1> ohh im now very confused :D
<squeek502> note: i have zero knowledge of how stage2 works
<g-w1> i thought i did but something must have changed ;)
<squeek502> but it seems like all compile errors would trigger the if branch, meaning if compileLog errors allow emitting an exe, then any error would?
<squeek502> which seems wrong?
<g-w1> i have the feeling that my memory is failing me; let me dig through the code for a few minutes
<g-w1> ok yeah it was
<g-w1> ignore what i said sorry about that, but it could be *very* easy to change it so that binaries are emitted even with compile logs (like a few lines of code easy)
<squeek502> right, but the compilation failing is intended for now, which is what that proposal is suggesting to be changed
<g-w1> yeah ill update my comments very sorry about that
<squeek502> np :)
<g-w1> but to go back to my previous point, when compiling an even invalid binary, stage2 will still emit a file with the start of an elf thing for incrimental compilation. so i dont think it would be out of the spec to emit a (complete) file because one (non-complete) will be emitted even when compilation fails
a_chou has joined #zig
mikdusan has quit [Quit: WeeChat 2.5]
mikdusan has joined #zig
<daurnimator> g-w1: the whole point of a "complete" file is so that the compilation runs again
<daurnimator> g-w1: @compileLog is inherently uncacheable: you want to do the compilation again to generate the log message again
<g-w1> Module.zig has a field called compile_log_text that stores the compile log output. with https://github.com/ziglang/zig/issues/6538 this will be serialized and when the compilation is re-run it will be re-printed
<g-w1> this is how I thought of it, not sure if im making mistakes in my logic
mikdusan has quit [Quit: WeeChat 3.0.1]
midgard_ has joined #zig
midgard has quit [Ping timeout: 246 seconds]
a_chou has quit [Remote host closed the connection]
ky0ko has quit [Remote host closed the connection]
earnestly has joined #zig
earnestly has quit [Ping timeout: 272 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
rowbee has quit [Quit: ZNC - https://znc.in]
rowbee has joined #zig
leon-p has quit [Quit: leaving]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
cole-h has joined #zig
sord937 has joined #zig
geemili has quit [Ping timeout: 240 seconds]
geemili has joined #zig
<dch> how does zig deal with speculative execution ? https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html is this taken care of already "because clang/llvm" ? and if so, would this change with native zig compilation?
<dch> sorry for the handwavey question
<marler8997> seems like a hardware issue that can't be solved with software
<ikskuh> heya o/
<ikskuh> marler8997: i don't think having prebuild.zig is a good idea
<ikskuh> i talked to andrew a bit yesterday and what gyro is doing is the proper way to do this
<marler8997> what way is that?
<ikskuh> compile your own build runner
<marler8997> huh?
<dch> marler8997: typically we need microcode update & compiler functionality like retpoline to address these, and yes some of them are basically "get a better cpu"
<dch> I'm mainly curious if zig inherits any llvm protection mechanisms by default, and how an eventual fully self hosted compiler might change that
<marler8997> what does "compile your own build runner" mean?
<ikskuh> marler8997: exactly what i'm saying
<ikskuh> "zig build" is just compiling a build_runner.zig which then invokes Builder.make()
osa1_ has joined #zig
<marler8997> so what makes this method better than prebuild.zig?
<ikskuh> it's way more flexible
osa1 has quit [Ping timeout: 265 seconds]
geemili has quit [Ping timeout: 272 seconds]
<marler8997> how so?
<ikskuh> you can add packages to build.zig for example
<ikskuh> you define the build mode
<ikskuh> you can do multiple runs of the build() function that allows certain things
<marler8997> oh because you're customizing how build.zig is built, whereas with prebuild.zig, you're not customizing how build.zig is build
<ikskuh> exactly
<marler8997> interesting
<marler8997> what's your github name?
<ikskuh> mine? MasterQ32 *laughs*
<marler8997> dch, sorry I'm not too familair with that, you might have to ask another time since it seems no one is responding right now
<dch> marler8997: np, I'm sure eventually somebody will poke it with a stick. thanks!
<marler8997> ikskuh, what do you think I should name my subbuild file? realbuild.zig? childbuild.zig?
<ikskuh> no idea
<ikskuh> for me it feels like a workaround for not having a builtin package manager right now
<marler8997> I feel like I don't need a package manager, I just need a way to request file trees
mikdusan has joined #zig
<ikskuh> which is what the zig package manager will do, eventually :D
<marler8997> well, that's what I'm working on
<marler8997> hmmm, I'm seeing a problem with this method
<marler8997> how do I forward all the options from the child build to the main build?
<marler8997> the options are part of what's generated by my dependencies
<ikskuh> if done right, you can run build(b: *Builder) twice ):
<ikskuh> once for determining the options and their values
<ikskuh> once for updating the refs
<marler8997> are the options supposed to be determined on the first run or the second?
<marler8997> because I can't do it on the first pass, they won't be availble till the second pass when I've retrieved my dependencies
<ikskuh> hm
<ikskuh> can't you just fetch all deps?
<marler8997> that's what the first pass is for
<marler8997> I can't use the deps on the first pass that's the whole point of the first pass :)
<marler8997> otherwise, I'll just geting compile errors about failing imports
<ikskuh> not sure if it's a good idea to declare the deps in build.zig
<ikskuh> but what is possible:
<marler8997> I'm not sure what you mean by "declare the deps"
<marler8997> I'm not declaring them in build.zig, there in my subbuild.zig
<ikskuh> pub fn declareDeps(dependency_manager: *marler.DependencyManager) void;
<ikskuh> pub fn build(b: *Builder) void;
<marler8997> I'm not sure what this has to do with getting the options from the dependencies into zig build
<marler8997> I have project A which depends on project B, and project A wants to import files from project B into it's build.zig file
<marler8997> so with your solution, I split project A into build.zig, and subbuild.zig
<marler8997> subbuild.zig is what imports the files from project B
<marler8997> build.zig just builds subbuild.zig and calls it, but how do I forward all the options from one to the other?
<marler8997> I don't see a way to forward the call from build.zig to subbuild.zig, the "build" entry point doesn't support forwarding as far as I can tell
<ikskuh> don't use build.zig for this
<marler8997> This solution is easily solvable with prebuild.zig, how do I do this with your solution. I'm not seeing it but you said it was more flexible
<ikskuh> to build the build runner
<ikskuh> zig run prebuilt.zig
<ikskuh> done.
<ikskuh> this builds a build runner that runs build.zig :)
<marler8997> interesting, maybe that will work
<marler8997> I'll need a way to cause "zig build" to print an error that they need to run "zig run build.zig"
<ikskuh> oh true, that's also possible *grin*
<ikskuh> you can just do that with @hasDecl(@import("root"), "marlers_magic")
<marler8997> preppedbuild.zig
<marler8997> hmmm, how do I get the zig executable?
<ikskuh> invoke "zig env"
<marler8997> how does that give me the same zig executable that was used on "ZIG run build.zig"?
<marler8997> zig will have to pass itself to the resulting build executable somehow, is it doing this?
<marler8997> shoot, this means we'd have to patch "zig run"
<marler8997> the only viable solution I can think of is to add an environment variable
<marler8997> ZIG_RUN_EXE?
<ikskuh> nah
<ikskuh> argv[0] is the solution ;)
<marler8997> that's already being used
<marler8997> in fact there was a bug for that already :)
<ikskuh> see std.fs.selfExeDirPathAlloc
<marler8997> for what reason?
<ikskuh> ah dang
<marler8997> I can't think of a good solution to this
<marler8997> it makes me think there's something wrong with this solution, like we're missing something
<ikskuh> you can also query your parent processes i think
<marler8997> not with execve
<ikskuh> ah true
<marler8997> I think the fundamental problem here is that zig needs to be involved during the whole process, it can't build an exe and peace out in the middle of the build
<marler8997> the problem with "zig run" is that the zig exe is gone, the problem with "zig build" is that the entry point is not flexible enough
<marler8997> I think the right solution is going to involve actually hooking into zig build somehow
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
jokoon has joined #zig
falsebla1 has quit [Ping timeout: 246 seconds]
falseblah has joined #zig
zags has joined #zig
earnestly has joined #zig
cole-h has quit [Ping timeout: 256 seconds]
<zags> jeezus, I keep doing zig commit and git run :D
<ikskuh> zags: yeah
<zags> i'm not alone? :D
<ikskuh> just write two shell scripts "zig" and "git" that just dispatch the right command
<ikskuh> no, you're definitily not
<zags> haha
Swahili has joined #zig
Swahili has quit [Read error: No route to host]
Swahili has joined #zig
<dutchie> oh nice, the fosdem videos are up: https://video.fosdem.org/2021/D.zig/
jokoon has quit [Quit: Leaving]
<Swahili> In Zig, we keep the tests in the file, at the bottom. Sorry, I think I read this somewhere but couldn't find it in the docs now ( https://ziglang.org/documentation/master/ )
<ifreund> you can put tests wherever you want in zig
<zags> about that, can i tell zig test not to run tests recursively on imported files?
<ifreund> no, but you can use --test-filter if you want to isolate a test case or cases
<zags> yeah, i know about that one, but it's not of much help here
<zags> a --test-shallow or something would be great
<Swahili> How to use a type from an import? For example, https://paste.sh/DbUbE_4S#U69g5qHuUXqO-b5DO-IbsyPQ
<ifreund> that looks right
<Swahili> Thanks for looking! What If I wanted to do an array of a particular struct? could I do []foobar.Foobar { { .x = 1, .y = 4} } ?
<dutchie> []foobar.Foobar{ .{ .x = 1, .y = 4} }
<dutchie> or []foobar.Foobar{ foobar.Foobar{ .x = 1, .y = 4 }}
<Swahili> Interesting! Thanks a lot : )
<dutchie> you can also do `const Foobar = foobar.Foobar` to make things a bit shorter
<Swahili> Yeh, that sounds good!
<dutchie> oh, you'll want [_] instead of []
<Swahili> Right! to have the length inferred, thanks : )
linuxgemini5 has joined #zig
<ifreund> [] is a slice not an array
sebonirc has quit [Ping timeout: 240 seconds]
companion_cube has quit [Ping timeout: 260 seconds]
linuxgemini has quit [Ping timeout: 272 seconds]
linuxgemini5 is now known as linuxgemini
companion_cube has joined #zig
sebonirc has joined #zig
vesim has quit [Remote host closed the connection]
waleee-cl has joined #zig
<marler8997> ikskuh, have a look at this proposal/build.zig example: https://github.com/ziglang/zig/issues/8025
<marler8997> takes elements from what you were telling me earlier
donniewest1 has joined #zig
<ikskuh> i'm not sure if i find that good
<oats> I really appreciate zig's unnamed struct notation
<oats> .{ .x = 1 }
<oats> almost feels like row polymorphism
bitmapper has joined #zig
donniewest1 has quit [Ping timeout: 240 seconds]
leon-p has joined #zig
<Swahili> Let's say I have const input = "=+", if I do print("{}\n", .{ input[1] }) I get the decimal value for "+", so I assumed that I would get "+" when doing print("{s}\n", .{ input[1] }). What should I study/learn to understand what's going on here? Thanks!
<ikskuh> Swahili: read the implementation of std.fmt.format
<ikskuh> there's a huge doc comment on top of it explaining a lot
midgard_ has quit [Ping timeout: 264 seconds]
<Swahili> ikskuh: thanks for looking! I'll do : )
<ikskuh> no need to look, i wrote most of that comment :D
v0idify has quit [Ping timeout: 268 seconds]
v0idify has joined #zig
<Swahili> ikskuh: gosh, it did help! I can see the output now "+"
<ikskuh> \o/
andreyorst has joined #zig
midgard has joined #zig
g-w1 has quit [Quit: WeeChat 2.7.1]
jacob3 has joined #zig
geemili has joined #zig
Akuli has joined #zig
donniewest1 has joined #zig
zags has quit [Quit: leaving]
tane has joined #zig
<tane> howdy
<ikskuh> 'ello!
v0idify has quit [Remote host closed the connection]
v0idify has joined #zig
evbo has joined #zig
evbo has quit [Remote host closed the connection]
fputs has joined #zig
<ifreund> andrewrk: how would you feel about // zig fmt: (on|off) working anywhere in the file not just at the top level?
<ifreund> almost seems like it would be easier/cleaner to implement that way now that comments are no longer tokens...
<ifreund> I'm part way through trying to implement the current behavior but it's messy and doesn't work yet
a_chou has joined #zig
<andrewrk> ifreund, sounds good
<andrewrk> I think if you want to use your best judgement and modify some of the test cases in a way that seems reasonable, go for it
<andrewrk> if we break somebody's workflow, I'm sure we'll have time to address it
fputs has quit [Remote host closed the connection]
<ifreund> sounds good to me :)
<ifreund> running zig fmt on parts of the std after we are passing the test suite should help find edge cases (for which we can then add more tests)
<jacob3> would it make sense to put a zig fmt check in the ci? some files in std aren't formatted correctly and i think a check would fix that
jacob3 is now known as g-w1
<ifreund> I'd say yes, it could be a simple github actions job
<g-w1> ok, ill work on that, although i think it would be better to put it in the ci scripts
dvaun has joined #zig
fputs has joined #zig
<ifreund> g-w1: don't forget about zig fmt --check
<ifreund> and that you can pass it directories
<g-w1> yep, doing that rn
<g-w1> zig fmt --check test/stage1/behavior/bugs/4769_c.zig fails, but it was added on purpose. this is an inconsistency between stage1 and stage2
<g-w1> should I delete it?
plumm has joined #zig
<ifreund> g-w1: I think adding // zig fmt: off at the top of the file would be the right solution
<g-w1> ok
<ifreund> actually wait, that's not vaild zig is it?
<ifreund> doc comments need a decl I thought
<g-w1> yeah, thats y i was confused
<g-w1> stage2 flags it, stage1 doesn't; i think it would be better to just remove it
<ifreund> I'd delete it then yeah
<g-w1> ok
jukan_ has joined #zig
<ifreund> g-w1: you need // zig fmt: off for test/stage1/behavior/bugs/4769_a.zig
<ifreund> the missing newline at the end of the file is intentional
<ifreund> same with 4769_b.zig
<g-w1> ah, I was wondering what to do with that. ok
jukan has quit [Ping timeout: 256 seconds]
xackus has joined #zig
<andrewrk> I'm not ready to fail pull requests due to improper zig fmt yet
<andrewrk> zig fmt is not quite up to the quality point that I think it makes sense to do that
<ifreund> I think with the more granular // zig fmt: (off|on) it would be fine
zags has joined #zig
<andrewrk> we're about to add a bunch of instability to it though with this branch
<andrewrk> I predict a couple undetected bugs
<ifreund> true
<andrewrk> we'll get there. I just think it's not quite time yet
<g-w1> should I change the pr into just formatting the code?
<g-w1> the reason I am doing this is because I get annoyed when my editor formats the code and then the diffs get messed up
a_chou has quit [Ping timeout: 264 seconds]
<andrewrk> I think that PR would introduce unnecessary conflicts with the big branch where we have slightly changed the zig fmt rules
<g-w1> ok, I can do it after, thanks
<andrewrk> sorry, I agree that is an annoying problem and that your proposed solution would fix it
cole-h has joined #zig
<zags> Let's say I have an ArrayList(MyType), i.e elements are values. If I make a local (on stack) struct instance and then immediately append that (and never touch the local again), does that still introduce a copy, or is it elided by the compiler? If not, is the plan to make it so? :D
<ifreund> llvm should be smart enough to elide that
a_chou has joined #zig
<zags> ifreund: i see, it's sometimes not just an optimization, as the object may hold non-copyable things like allocators, so knowing what guarantees exists in 1.0 would be great
<zags> in c++ i would make these things non-copyable, not sure if something similar is planned (or if it's possible without constructors)
<ifreund> Once pinned is implemented copying pinned things will be a compile error
<zags> that will go a long way
<ifreund> the answer here though is that no, zig does not and probably never will guarentee that the copy will be elided in this situation
<zags> i see
<ifreund> use ArrayList().addOne()
<zags> in this case... excellent point :D
Swahili has quit [Remote host closed the connection]
<zags> hm, then I have to change around error handling. I can't seem to combine decl and catch: var x = list.addOne() catch |err| {...}
<zags> that's a compile error, what's the correct idiom?
<ifreund> you can do that, but your catch block needs to evaluate to either noreturn or *T
<zags> hm
<zags> ah, gotcha, thanks
<tane> realizing polymorphism and ownership in a collection doesn't seem super trivial
<tane> if it's all on the heap, the embedded struct (like Allocator) would also need something like a `deleteFn`, right?
<tane> to retrieve its parentpointer and then deallocate from there
<andrewrk> my showtime talk is in 15 minutes, on the topic of portable linux binaries that can open a window and use vulkan drivers
<ifreund> nice, zig fmt: (off|on) works everywhere now
<ifreund> andrewrk: if you have a minute before the stream, would you rather integrate AutoIndentingStream even more tightly with zig fmt or use a nice mutable global like I'm doing now?
<andrewrk> uhh not sure, but I will say that I feel a little skeptical about AutoIndentingStream and wouldn't mind special casing it for zig fmt
kristoff_it has joined #zig
<ifreund> Yeah I don't think it's very generally useful outside of our formatting implementation
<ifreund> I think I'll move it to render.zig and make it not pub
<andrewrk> I support that
<ifreund> urgh, the C backend uses AutoIndentingStream as well
hnOsmium0001 has joined #zig
<ifreund> C backend doesn't use much of it though, I'll just leave a minimal IndentWriter in that file
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
ss141309 has joined #zig
plumm has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
v0idify has quit [Ping timeout: 268 seconds]
Techcable has joined #zig
<zags> going back to error handling in c++ gives me nausea :( dealing with a mixture of bools, ints, error_code's and exceptions >.<
<Techcable> :laugh:
<zags> when zig world domination
<Techcable> Nah, just C domination
<ifreund> zig replaces C++ for me as well
<Techcable> Yeah, its very clean :)
<Techcable> What about Rust?
<ifreund> I'd take Rust over C++, but Zig or C over Rust
<zags> :D
<ifreund> though that does depend more on the use-case
<zags> i'm reasonably friendly with the borrow checker now, but I still don't like the language
<Techcable> Really?
<Techcable> I mean it's a little over-complicated
<ifreund> more than a little
<Techcable> he he he
<zags> lots of unnecessary mental load
<Techcable> Well a lot of that abstraction is nessicarry to deal with the borrow checker and its safety features
<ifreund> definitely better than C++ though
<zags> especially as a second language
<zags> ifreund: for sure, but that's not saying much now is it? :LD
<ifreund> nope not at all :D
<Techcable> One thing I really don't like is how bloated the applications are :(
<ifreund> compile times and portability are also not good
<Techcable> Prtability always seemed great to me
<Techcable> Pretty much all platforms are supported
<Techcable> But compile times are attrocious due to LLVM and their implementation of generics
<Techcable> I have a simple command line app that takes 2.4 MB
<ifreund> Techcable: may I introduce you to https://github.com/pyca/cryptography/issues/5771
v0idify has joined #zig
<Techcable> Hmm
<ifreund> and compile times can't be blamed entirely on LLVM, C compiles far faster with clang which is also LLVM based
<Techcable> Oh no no no no
<Techcable> its 99% because of rust's design choices
<Techcable> By designn, Rust requires optimization to achieve reasonable performance
<fengb> They throw millions of junk instructions to LLVM hoping it'd be cleaned up
<ifreund> heh
<Techcable> Yes
<Techcable> Its "zero-cost" abstractions are only zero cost at llvm -O3
<ss141309> Hi! I am trying out zig, but zig build gives the following error: "error: unable to find zig installation directory: FileNotFound". Zig is compiled from source. How can I resolve this?
<Techcable> ss141309, Why are you trying to compile from source?
<Techcable> Is there a specific reason you want that?
<ifreund> ss141309: it sounds like you've move the zig binary somewhere but not he lib directory
<ss141309> wanted to try out ziglings, the tar version also gave the same error
<Techcable> Hmm
<ifreund> the zig binary needs to stay at the same relative path to the lib dir
<Techcable> What system are you on?
<ss141309> linux
<ifreund> if you simply unpack the tarball and run it withough moving anything it should work
<ss141309> where should i unpack the tarball?
<ifreund> wherever you want, it doesn't matter
<ifreund> the only thing that matters is the relative path between the zig binary and the lib dir
<ss141309> it does not need to be on the path?
<Techcable> I would assume so
<ifreund> if you want to add it to your PATH you can do that yes
<ss141309> ok thanks, i will try it
<Techcable> You could just export it at the command line :)
<Techcable> export PATH="$PATH:path_to_zig"
<ss141309> it is working now, thanks!
ed_t has joined #zig
<ed_t> I want to do something like: self.x = async f();
<ifreund> no problem, have fun with ziglings!
<ed_t> how should x be declared in the structure?
<g-w1> I think @Frame(f)
<ifreund> ed_t: @Frame(f)
<fengb> x: @Frame(f)
<g-w1> lol
<ifreund> jinx g-w1 fengb
<fengb> Pfft, you tried to redeclare ed_t
ss141309 has quit [Quit: Connection closed]
<ed_t> thanks. If f is not known at comptime is there a way to declare that too?
xackus has quit [Read error: Connection reset by peer]
xackus has joined #zig
<fengb> Not completely, but you can fake it with a manual bytes
<fengb> With @asyncCall, you can use an existing byte slice as the frame location
<ed_t> thanks fengb. the help given on this channel makes learning zig less frustrating.
<fengb> Oh well... async might lead you to a lot more frustration >_>
<ed_t> fengb I am well aware of async and how much of a pita it can be.
xackus_ has joined #zig
<ed_t> and yes I expect async, when I start really using it, to lead to some 'interesting' buglets
<ifreund> async is also still quite experimental in Zig, more of a PoC than anything else
xackus has quit [Ping timeout: 240 seconds]
<ed_t> I sort of like the zig model for async. It should let me create a tool similar to the old IBM pipelines tool fairly 'easily'
<ifreund> oh yeah I think zig's approach to async is very promising
<ed_t> two decades back I create a java/netrexx version but java's threading model make it hard. zig's on the other hand. fits the problem like a glove
<ifreund> it's just not quite finished yet :D
<ed_t> how stable do you guess the interface is?
Snaffu has joined #zig
<ed_t> stable as in language stable
<ed_t> and what needs to be added?
GrooveStomp has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
Swahili has joined #zig
<ifreund> well, select for one
<ed_t> reading thanks
<ifreund> hard to say how much the interaface will change
<ed_t> for what I want to do select is not needed (at least at the start)
xackus has joined #zig
sord937 has quit [Quit: sord937]
xackus_ has quit [Ping timeout: 256 seconds]
Snaffu has quit [Quit: leaving]
<Swahili> I've got a struct where I store some input data and a test, where I iterate on the input. On a fn readNextCharacter, I get a "error: the following test command crashed", zig-cache/o/3594b7547857541b4baada4557e68389/test /usr/local/Cellar/zig/HEAD-300ebbd/bin/zig
<Swahili> Does anyone know what I'm doing wrong? Thanks!
<Gliptic> <= is wrong
<Gliptic> for one
<ikskuh> Swahili: you are returning a pointer to stack memory in "new"
<ikskuh> just do not return a pointer but a value ;)
<ikskuh> instead of
<ikskuh> pub fn new(input: []const u8) *Foobar {
<ikskuh> do
<ikskuh> pub fn new(input: []const u8) Foobar {
<Swahili> Thanks for looking! I see, I'll try again!
<Swahili> Gosh! Thanks a lot! That worked! I should have asked before :~(
tane has quit [Quit: Leaving]
Akuli has quit [Quit: Leaving]
a_chou has quit [Ping timeout: 240 seconds]
plumm has joined #zig
donniewest1 has quit [Quit: WeeChat 3.0.1]
blackpawn has joined #zig