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/
bjorob has quit [Ping timeout: 265 seconds]
return0e has quit [Ping timeout: 265 seconds]
<daurnimator> CI currently failing?
return0e has joined #zig
<daurnimator> well; not on master. but lots of recent PRs are for what seems to be not-their-fault reasons
<kllr_sbstn> `zig build test-std` fails for me (on linux) in net.zig
<kllr_sbstn> ah, nevermind, old branch
<dimenus> the times, they are a changin!
<pixelherodev> Well that's what happens when people go around `touch`ing every part of the code base
<pixelherodev> Ooh, FIFOs in the stdlib? I can probably throw out my ring buffer classes and switch to those without issue, right?
<kllr_sbstn> Found a leak in the json parser :D
<daurnimator> pixelherodev: hopefully!
<pixelherodev> Definitely going to try later
<pixelherodev> Thanks for adding those!
<pixelherodev> That reminds me - if nobody implements the support for a custom OS definition in the root source file, I can tackle it in the first week of December
<pixelherodev> Possibly sooner
<daurnimator> pixelherodev: please let me know how you go with the fifo usage. It's ideally meant to map well to traditional socket calls/file reading+writing
<daurnimator> pixelherodev: e.g. there are two main "flows" for writing to it: 1. if you already have data in memory (e.g. a constant), then use fifo.write(). 2. if you need a buffer to write into, 2.1: if you don't care about the size, use fifo.writableSlice(0) then fifo.update(). 2.2: if you need a specific size, use fifo.writeableWithSize() then fifo.update()
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev> Thanks - is that in the docs also?
<daurnimator> partially. needs more docs and examples. 2.1 usage example: you're read()-ing from stdin
<daurnimator> 2.1 usage example: you're read()-ing from stdin, 1. fifo.ensureUnusedCapacity(1); 2. call fifo.writableSlice(0) to get a buffer. 3. pass that buffer to read(). 4. fifo.update with the result of read(). 5. now attempt to use the contents of buffer (e.g. pass to your parser); otherwise goto 1. to get more data
<daurnimator> 2.2 usage example: `const slice = try fifo.writableWithSize(4); mem.writeIntSliceLittle(u32, slice, 1234); fifo.update(4);`
<daurnimator> pixelherodev: ^ all make sense/sound good?
<pixelherodev> Yeah, think so
dimenus has quit [Remote host closed the connection]
<daurnimator> btw, if you can think of a better name than `FixedSizeFifo` please mention it
<daurnimator> I want to also make a variety that just takes a buffer to use rather than an allocator
kllr_sbstn has quit [Quit: leaving]
Jezza__ has quit [Ping timeout: 264 seconds]
squeek502 has quit [Quit: Leaving]
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
dimenus has joined #zig
squeek502_ has joined #zig
traviss has joined #zig
dimenus has quit [Ping timeout: 240 seconds]
squeek502_ has quit [Quit: Leaving]
muffindrake has quit [Ping timeout: 252 seconds]
muffindrake has joined #zig
<bhansconnect> Just wondering, anyone have any ideas what the performance implications of heap allocating recursive calls would be? Also, are there any plans to let developers choose between heap and stack allocation?
<fengb> Zig won’t have a default allocator so heap and stack will always be a choice
<fengb> Er, do you mean letting recursion happen on standard callstack like other languages?
<bhansconnect> Standard call stack like other languages
<bhansconnect> Also, if you use an allocator, won't that always be on the heap? And things without allocators would be on the stack?
<fengb> FixedBufferAllocator is stack based
<fengb> Or global mem
<bhansconnect> Ok. That makes sense. Didn't think about it.
<bhansconnect> So technically you could use a fixed buffer allocator for recursive calls and it would be stack based like other languages.
<fengb> I think the goal is to make recursion memory safe. So if the compiler can know the max depth, that would provide enough safety
<scientes> but you can't really know that
<fengb> Although I’m not sure how that could work outside of tail calls
<bhansconnect> Makes sense. I am just wondering if safe recursion will cause performance issues
<bhansconnect> Also, you can use global heap allocation if you don't know how deep recursion will be
<bhansconnect> Then the recursion limit is the memory limit
<bhansconnect> Also, scientes you can simply say that you want to ensure recursion to specific depth and limit memory based on that(would be similar to Max stack size before overflow)
<fengb> When Zig is “done”, stack overflow should be impossible
<scientes> only because you have offloaded it
<fengb> The compiler would know max stack size at compile time and request that
<scientes> you can stick overflow stack structures
<bhansconnect> Cause either compiler knows depth or offloaded to heap, correct? And heap allocator will return out of memory error.
chemist69 has quit [Ping timeout: 276 seconds]
chemist69 has joined #zig
<bhansconnect> Thanks for the link
_whitelogger has joined #zig
brodeuralexis41 has joined #zig
brodeuralexis41 has quit [Remote host closed the connection]
doublex_ has joined #zig
doublex has quit [Ping timeout: 276 seconds]
brodeuralexis has joined #zig
brodeuralexis has quit [Quit: Konversation terminated!]
ltriant has quit [Quit: leaving]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
jmiven has quit [Quit: bye]
jmiven has joined #zig
FireFox317 has joined #zig
return0e_ has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
knebulae has quit [Read error: Connection reset by peer]
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
mattmurr has joined #zig
knebulae has joined #zig
lunamn_ has quit [Quit: leaving]
return0e_ has quit [Remote host closed the connection]
return0e_ has joined #zig
return0e_ has quit [Remote host closed the connection]
return0e_ has joined #zig
tdc has joined #zig
return0e_ has quit [Remote host closed the connection]
return0e_ has joined #zig
return0__ has joined #zig
return0e_ has quit [Ping timeout: 265 seconds]
kllr_sbstn has joined #zig
kllr_sbstn has quit [Ping timeout: 246 seconds]
squeek502 has joined #zig
bentxt has quit [Remote host closed the connection]
kllr_sbstn has joined #zig
kllr_sbstn has quit [Read error: Connection reset by peer]
kllr_sbstn has joined #zig
forgot-password has joined #zig
return0e_ has joined #zig
return0__ has quit [Ping timeout: 240 seconds]
<SyrupThinker> I want to extend uefi protocol support in std (std.os.uefi.protocols). The implemented protocols are all just wrapping the C api. Is this preferred to creating a more zig-like api?
<SyrupThinker> For example the File protocol takes a buffer size and a pointer. In the Zig function I'd take a slice instead.
<SyrupThinker> Similar thing for bitflags where only specific combinations are allowed. I would expose a enum allowing only those combinations.
return0e_ has quit [Remote host closed the connection]
return0e_ has joined #zig
dimenus has joined #zig
waleee-cl has joined #zig
kllr_sbstn has quit [Ping timeout: 268 seconds]
kllr_sbstn has joined #zig
<leeward> Isn't knowing the max stack size at compile time with recursive programs the halting problem?
<leeward> Or are you saying that stack overflow won't be a problem because it will be heap exhaustion?
doublex_ has quit [Ping timeout: 240 seconds]
dimenus has quit [Remote host closed the connection]
kllr_sbstn has quit [Ping timeout: 252 seconds]
<FireFox317> andrewrk: How would you suggest to translate the following in Zig? Because current packed structs don't work that nice (#3133). https://github.com/LdB-ECM/Raspberry-Pi/blob/33b176202b5ee12e19ed8757526190e62efb2975/Arm32_64_USB/rpi-usb.c#L322
<FireFox317> Or somebody else :)
<mq32> omg. https://github.com/LdB-ECM/Raspberry-Pi/tree/master/GLES2 i am in love and i have to dig through the code
kllr_sbstn has joined #zig
<fengb> leeward: unbounded recursion will be handled by manually shifting the callstack into the heap
doublex has joined #zig
<fengb> I'm hoping bounded recursion can still be semi-solvable. At the very least, tail calls can be addressed
kllr_sbstn has quit [Ping timeout: 240 seconds]
<leeward> fengb: Doesn't that turn into implicit allocation?
doublex has quit [Ping timeout: 264 seconds]
<leeward> Or is this a `shiftStackToHeap(allocator)` kind of thing?
<mq32> leeward: no, you have to code it by hand
<tgschultz> FireFox317 what am I missing? That doesn't look like it should be a problem for current packed structs.
doublex has joined #zig
<tgschultz> nevermind, I see it now. some of these structs are align(4)
return0e_ has quit []
<FireFox317> tgschultz: Actually now that you are saying that, it works quite okay. I can probably work around that align(4)
Kappa322 has joined #zig
<mq32> FireFox317, can't you just make the required variables align(4)?
<FireFox317> Yeah that was actually not the problem XD
<FireFox317> It was just me being stupid
<mq32> oh, the classic :D
<mq32> i had this at work today
<mq32> "yeah, this doesn't work i have to search … hours for a bugfix"
<mq32> 2 minutes later
<mq32> "oh. beat me, i just messed up a single setting."
dimenus has joined #zig
<dimenus> can structs have constant members now that we have default init
<dimenus> *?
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
forgot-password has quit [Quit: leaving]
wilsonk has quit [Ping timeout: 240 seconds]
wilsonk has joined #zig
halbeno has quit [Read error: Connection reset by peer]
halbeno has joined #zig
lunamn has joined #zig
kllr_sbstn has joined #zig
ky1ko has joined #zig
ky0ko has quit [Ping timeout: 268 seconds]
wootehfoot has joined #zig
kenaryn has joined #zig
<kenaryn> Hi strange people who love computers more than humans. I would like some help, if someone is willing to, to build my very first program who throw me into my face: `error: expected type 'usize', found '[]u8'`
Akuli has joined #zig
<kenaryn> The source can be found here: https://godbolt.org/z/pZUfp_
<dingenskirchen> consider using title.len?
<kllr_sbstn> line 48: `title` is of type []u8 (a string)
<kenaryn> I tried replacing the buffer type by 'usize' of course (i.e. line 18), but then a new error appeared: `slice of non-array type 'usize'`
<kllr_sbstn> buffer[0 .. title.len]
<kenaryn> Very nice, it now compiles. Thank you.
<kenaryn> Did you notice inconsistency or idiosyncrasies that may be fixed/improved?
<kllr_sbstn> why do you create your own error types?
<kenaryn> Nevermind, but another question is now raised, the line including write did stoped at the end of line, please how can I add `\n` escape sequence into a slice?
<kenaryn> Ah sorry, did not seen your answer in time. It is in order to gain some performance over the error global set!
<kenaryn> Because the official documentation tells there cannot be some optimizations done (I suppose inlining and the like).
<kllr_sbstn> add another write call `file.write("\n");'
<kenaryn> You are kind. Thanks :)
<dingenskirchen> I believe the "global error set" refers to anyerror, which you are using currently
<dingenskirchen> You should be able to elide both the error definitons (which your code doesn't use) and "anyerror" from main's signature without any loss except in LOC
<kenaryn> Yes, I was refering to `anyerror`. I thought it was good practice to define its own error set to let the compiler have more informations and determine some optimizations.
<kenaryn> On the other end, adding at the end `file.write("\n")` now throw an new error: `expression value is ignored`
<Kappa322> That's because you're ignoring the result of it. You need to wrap it in a catch like on line 30-32
<kenaryn> Does it need a new whole wrapping just to add a sequence espace character?
<dingenskirchen> you can also shorten `foo() catch |x| return x;` to `try foo()` in pretty much all cases, as zig will still display an error returned by main and they have fairly descriptive names of their own
<kenaryn> It seems very verbose.
<Kappa322> Yes.
<Kappa322> The more correct way of doing it would be concatenating "\n" to the end of the buffer
<Kappa322> and in that case you only have one write
<kenaryn> Ah great! nice catch (joke inside).
<Kappa322> Generally if you care about performance, the less times you call disk operations like file.write, the better
<kenaryn> Yes, I understand. But `++` array concatenation only works when values are known at compile-time, so I guess I have to give a try with fmt.bufPrint but I will take another memory allocation at run-time.
<kenaryn> Thank you digenskirchen, almost forgot to stay polite :)
<kenaryn> `file.write(buffer[0..title.len] ++ "\n")` throws: error: unable to evaluate constant expression.
<dingenskirchen> No problem at all ^^, you might want to use std.Buffer for a while allocating rather convenient API
<Kappa322> You'd probably want to read at maximum one character less than your buffer
<Kappa322> and then just set the character after the last character in the input to "\n"
<dingenskirchen> also a valid approach and avoids heap allocations completely while at it
<mq32> dingenskirchen, Kappa322, kenaryn: File should have a stream property that will guarantee easy use
<mq32> whereas file.write doesn't guarantee that the content is fully written (at least to my knowledge)
<mq32> i cannot look at the godbolt source though
<kenaryn> I'm willing to add a stream property but what does it mean in English (or in French for that matter :D)?
<kenaryn> I just added try std.io.readLineSlice(buffer[0..buffer.len-1]) and it compile for now but add the last character in the same disk operation seems a bit challenging for me :p
wilsonk has quit [Ping timeout: 276 seconds]
<mq32> assuming "file" is a *File:
<kenaryn> It's like mandarin lol. How can I "assume" that?
<mq32> i'm assuming
<mq32> i cannot look at your code
<mq32> var stream = file.iutStream(); try stream.print("My Text: {}\n", buffer);
<mq32> *outStream()
<kenaryn> Do you want a bpaste.net snippet?
<mq32> nah, doesn't help either :D
<mq32> i have 40kBit/s internet
<mq32> even a handshake for https takes a minute
<kenaryn> I started at 5kbit/s in 1999 and I was lucky :)
<mq32> yeah but then *everythin* was small
<mq32> now a https handshake is just ... big
<kenaryn> True, even my ego back then... :D
<mq32> lol
<mikdusan> why readLineSlice()? use a std.Buffer then append to it. `std.io.readLine(&buf)` then buf.appendByte('\n') and now you have a nice buf.toSlice()
<kenaryn> Did you mean OutStream() instead of iutStream?
<Kappa322> Something like that is what I meant
<mq32> outStream(), yes
<mq32> not OutStream :D
<Kappa322> Although mq32 is probably way more experienced with zig file io than I am
<Kappa322> So listen to him :)
<mq32> Kappa322: thanks, i'm just someone with too much time to read issues on github
<kenaryn> When you assign at line 19, does it append or just reference?
<Kappa322> Neither; it assigns
<kenaryn> Allright, thanks. I will try the mq32 solution if he's the second BigBoss here.
<mq32> haha lol
<Kappa322> buffer is just an array of bytes, so your buffer would look something like ['b', 'o', 'o', 'k', ud, ud, ud, ud] (ud for undefined), pretending it's 8 bytes large
<Kappa322> this would set the 5th byte to '\n' instead, but the space to put it in is already there if that makes sense
<Kappa322> ps: if you didn't know, \n is just one character, not two
<Kappa322> Even though there are two characters when you write it out, the compiler will translate it to one, ascii 10
<kenaryn> Ah thank you, I will document all of this in a memorandum.
wilsonk has joined #zig
<mq32> okay, as my train has now arrived: back to hacking weird freestanding stuff with zig
<mq32> let's break the compiler once more!
<kenaryn> Yes we want Tier1 support already :D
<andrewrk> the poor stage1 compiler. all it ever wanted was to build self-hosted, but we're making it do so much more
<mikdusan> stage1: “I didn't sign up for this”
<mq32> andrewrk, yeah true. but it's good to test the language itself on as many possible use cases as possible before starting stage2
<andrewrk> true, it's good to collect all these test cases
<mq32> you never know what may need to change
kllr_sbstn has quit [Quit: WeeChat 2.6]
<Kappa322> andrewrk, is building c++ with build.zig supposed to work? I see that the zig project itself uses it for c++ but don't know if it actually works?
<andrewrk> it's something that will be supported but I haven't tested it much yet
<andrewrk> where do you see zig using it for c++?
<Kappa322> addCppLib in the build.zig
<Kappa322> Or is it reusing the object files from gcc/clang and just linking them?
<mq32> andrewrk: would it be possible to query doc comments from @typeInfo?
<andrewrk> Kappa322, yeah it's reusing libzig_cpp.a when it links self-hosted :)
<andrewrk> I was pleased when I realized that would work just fine
<Kappa322> Fraud!
<Kappa322> :D
<andrewrk> zig is designed to bootstrap with a small number of steps
<andrewrk> oh I realized why the chat server from the live stream stopped working after a while
<mq32> tell us the secret!
<andrewrk> https://gist.github.com/andrewrk/4ca4badce653619d0804464c2e400220#file-server-zig-L68 after a client disconnects this write() call (we also had it as send() with MSG_NOSIGNAL) returns an error, and the loop stops
<andrewrk> that logic has to catch such an error and remove the client from the hash table
<mq32> ah yes
<mq32> makes sense
<andrewrk> or at least continue with the loop
<andrewrk> I'm glad it was simple logic that was wrong in the code rather than like some design flaw in the standard library
<kenaryn> mikdusan, I do not understand your Jedi knight technique, I would like to print a user input to stdout AND write it to an external file. If you agree to look upon: https://godbolt.org/z/WW6_Wh
FireFox317 has quit [Remote host closed the connection]
wilsonk has quit [Read error: Connection reset by peer]
FireFox317 has joined #zig
bjorob has joined #zig
Kappa322 has quit [Remote host closed the connection]
<mq32> kenaryn: have you taken a look at the stdlib docs?
<mq32> the "stream" thing i meant earlier looks like this:
<mq32> var stream = file.outStream();
<mq32> try stream.stream.print("{}\n", title);
Kappa322 has joined #zig
Jezza__ has joined #zig
wilsonk has joined #zig
<mikdusan> kenaryn: unless i missed something in chat, something like this: https://gist.github.com/mikdusan/9a99082dced5f014f390e22e3d134d7c
traviss has quit [Read error: Connection reset by peer]
<kenaryn> thank you both mq32 and mikdusan, I'm looking into it right now but it's still traditional chinese for me, perhaps adding a simple use case in the standard library documentation would facilitate the understanding and lower the entry barrier and misinterpretation's risk.
<kenaryn> For each namespace, fields and functions I mean, but no rush, it could be appended during the next months.
<mq32> kenaryn: i don't think that's reasonable yet as everything in zig is right now "with the licence to break"
<kenaryn> A simple, comprehensive and increasingly's level difficulty could be a backbone for a yet-to-become book, which in return could bring benefits to the creator and/or a fundation to finance Zig's long-term development.
<kenaryn> Yes, you are right.
<mq32> most blog entries about zig are wrong with some stuff already again
wilsonk has quit [Read error: Connection reset by peer]
<mq32> even andrews second-latest blog entry from a year ago doesn't work anymore with current zig library and code
<mikdusan> kenaryn: if it helps i added some comments to that gist. anyhow i have to take off for a bit.
<mq32> andrewrk: does an @embedFile() call always gets embedded into the binary or only if i store it into a symbol?
<kenaryn> Astonishing! Thank you already mikdusan
<kenaryn> Allright, I hope andrew will update one day his entry with regard to writing freestanding code. I think it is essential that programmers learn more about hardware and instruction set architecture in general.
clktmr has joined #zig
<andrewrk> mq32, lazy analysis applies, so if you never reference it, it won't get included
<mq32> okay, neat
<mq32> but if i copy a single byte, it will get included fully, right?
<andrewrk> but zig doesn't have comptime garbage collection yet, so if you for example did an inline loop over it, but don't actually keep a reference to it for runtime, it'll unfortunately still get included
<mq32> okay, thanks :)
<andrewrk> once zig is done, copying a byte would not mean it gets included, but currently that will be the case
<andrewrk> with optimizations on, it should get deleted though, if it's not referenced at runtime
<mq32> yeah it would be unreasonable to implement it like that in a final compiler, but for now that's fine :)
<mq32> then i will write a preprocessor instead of using comptime generation
<scientes> llvm also lacks GEP optimizations
<scientes> like what you are talking about mq32
<kenaryn> Including a garbage collector risk breaking the community into two sides, the Dlang never took off for this reason (and another, but it's off-topic).
<mq32> GEP?
<scientes> GetElementPointer
<andrewrk> kenaryn, I don't think you have the correct understanding of the topic, comptime garbage collection is not the same thing as runtime garbage collection
<scientes> or just any optimizations on global constants
<scientes> there are a few weird transformation you can do, if a global is only used in one place
<andrewrk> comptime garbage collection is a detail that almost nobody has to care about
<scientes> and also just DemandedBits optimizations
<scientes> will you can also reorganize the data
<kenaryn> Allright, dully noted. Thanks for your honesty.
<mq32> but yeah, @embedFile is one of those features i love as an embedded programmer ):
<mq32> * ):
<mq32> *** :)
Akuli has quit [Quit: Leaving]
<andrewrk> comptime garbage collection applies when you write code that runs at compile time, that creates a self-referential data structure in comptime memory. the compiler needs to figure out that it doesn't actually have to put the comptime data into the binary
<mq32> before zig you had to "compile" your binaries into an ELF object file (which is quite uncomfortable) and then link against it and use exported symbols
<scientes> oh yeah these features are great
<scientes> mq32, or like the really ugly stuff in Linux to do the same thing
<scientes> generating a C file with an array of bytes
<mq32> what do they do?
<mq32> oh yeah
<mq32> that is even more horrible
<mq32> it slows down the compiler soooo much
<mq32> "oh yeha, please compile this 1MB source file
<scientes> also requires perl
forgot-password has joined #zig
wilsonk has joined #zig
<kenaryn> I have an existential question, how should I know if my variable belong to the stack or the heap category?
<scientes> kenaryn, zig does not have a concept of a heap
<scientes> so its either stack or register, or you use a library to get it on the heap
<mq32> kenaryn: simple! everything that is *local* is "stack", everything *global* is global/static memory and everything that gets allocated by a "heap" allocator (c_allocator, direct_allocator) is heap
<kenaryn> Do you think it is a flaw in language design, or is it intended to keep the language small and simple?
<scientes> oh yeah, forgot static allocations
<scientes> kenaryn, it is very explicit
<mq32> kenaryn: it's not a flaw but an excellent thing that zig gives you control over that
<kenaryn> Thank you both again :)
<mq32> pixelherodev: do you already have a working "page allocator" for RAM pages?
Kappa322 has quit [Remote host closed the connection]
ltriant has joined #zig
forgot-password has quit [Quit: leaving]
lunamn_ has joined #zig
FireFox317 has quit [Ping timeout: 276 seconds]
lunamn has quit [Ping timeout: 240 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
wootehfoot has quit [Read error: Connection reset by peer]
FireFox317 has joined #zig
<dimenus> has anyone done a BumpAllocator yet?
<andrewrk> dimenus, std.heap.FixedBufferAllocator
<dimenus> tahnks
<dimenus> *thanks
shakesoda has joined #zig
vexu has joined #zig
bjorob has quit [Ping timeout: 240 seconds]
jjido has joined #zig
kenaryn has left #zig ["Keep up the good work and thanks for the overall kindness!"]
<dimenus> does it make sense to be able to specify a block size with the ArenaAllocator?
clktmr has quit [Ping timeout: 240 seconds]
FireFox317 has quit [Ping timeout: 240 seconds]
traviss has joined #zig
vexu has quit [Quit: WeeChat 2.6]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]