<andrewrk>
and then finally var args will be fixed or deleted
<scientes>
including return inferred return types?
<tgschultz>
list literals hype.
<frmdstryr>
Got it, thanks
<andrewrk>
that's an entirely separate issue
<scientes>
oh var args
<scientes>
var args and args that are "var", heh
<andrewrk>
yeah, I wonder if `anytype` would be better than `var` for args
<tgschultz>
yeah actually that's a lot more clear
<andrewrk>
considering we have anyframe, anyerror, and there is a proposal for anyopaque
<andrewrk>
although I could see people getting confused and putting `anytype` where simply `type` would be correct
<scientes>
yeah thats a problem
<scientes>
but type wouldn't be valid there
<scientes>
or would it
<andrewrk>
I kinda wanted to make it inferred if you omit the type, but josh wolfe is strongly against it, because it will encourage people to not use parameter types
<scientes>
and that is the main argument against the whole thing
<scientes>
but it does allow nice stuff
<scientes>
and I don't think a language should be responsible for preventing the user from shooting themselves in the foot
<andrewrk>
that's the plan for var args too. `args: var` and then use reflection to iterate over the struct
<andrewrk>
std.fmt.format can support both array literals and struct literals. why not? so you could name your {}'s or have them be index based
<scientes>
yeah that doesn't seem entirely insane
<scientes>
even if they should generally be named
<scientes>
but it reduces the amount of type information in the source code
* shakesoda
likes inference for omitted types on args
<dimenus>
hmm, that PR didn't break a lot of things on my Vulkan testbed
<dimenus>
just a a bit of translate-c code
<dimenus>
kjj:q
<dimenus>
whoops, wrong window
<dimenus>
andrewrk: there was a missed cast in lib/std/target.zig:322
<andrewrk>
yeah I'm expecting there to be a handful of these
<andrewrk>
apologies in advance
<dimenus>
no worries, i opened a PR for the one I caught
<daurnimator>
andrewrk: around at the moment?
<andrewrk>
hi daurnimator
<daurnimator>
andrewrk: couple of open questions for you: 1. why isn't fifo in std library docs? => is it getting missed by the test suite or something? 2. I saw you mentioned a "zig foundation" again: did you see what I said the other day about SPI/SFC?
<andrewrk>
daurnimator, https://github.com/ziglang/zig/issues/3402 - I wanted to do some more work on generated docs before setting them up with CI builds. but I switched tasks to language stuff to keep myself fresh. I suppose I can implement #3402 for now
<andrewrk>
I missed your comments about SPI/SFC
<daurnimator>
andrewrk: SPI = software in the public interest. SFC = software freedom conservancy. They're both organisations that do all the book-keeping and other legal paperwork for open source projects
<andrewrk>
I sent an application to the SFC
<daurnimator>
andrewrk: ah okay. I talked to Karen about it a few weeks ago, I might be able to send a follow up if you want?
<andrewrk>
I'll look into SPI
<andrewrk>
sure, that sounds good
<daurnimator>
andrewrk: in general, SPI take 5% and don't do much. SFC take 10% and are more fully featured
<daurnimator>
andrewrk: ah doh. I didn't see that std lib docs are not built off CI
<daurnimator>
I thought I had missed something in my PR :P
<andrewrk>
daurnimator, as another example I don't like that the docs are for the x86_64-linux-gnu target only. I have a merge tool about 40% done
<daurnimator>
yeah I figured that was in progres
<andrewrk>
I pushed an update just now
<daurnimator>
andrewrk: thanks! https://ziglang.org/documentation/master/std/#std;fifo.FixedSizeFifo => I noticed the weird error set name for peekItem... so I clicked through to peekItem and I got a 404?
ftxqxd has quit [Ping timeout: 268 seconds]
<daurnimator>
I guess because FixedSizeFifo itself isn't public (that was an oversight; I've got a followup PR)
<andrewrk>
that's an anonymous error set, should be fine eventually, but as you can see not handled well currently
<daurnimator>
oh wait no sorry it is public
<andrewrk>
generic types aren't done yet either
<daurnimator>
so there's just the general question of: why are all the method docs 404
<daurnimator>
k
<andrewrk>
generic types and merging multiple builds together is the same problem
<andrewrk>
we'll get there
<daurnimator>
no problem
<andrewrk>
some of this is limitations in the js code
<andrewrk>
not the underlying semantic analysis json dump
<daurnimator>
so now with that fifo data structure, how should we start using that from e.g. the socket code? In some ways it partially replaces "Buffer". In others it sort of acts like an BufferedOutStream... and in others its an InStream
<andrewrk>
why would you use the fifo data structure and not InStream/OutStream?
<daurnimator>
andrewrk: compared to InStream, it allows for buffering the data you get. e.g. I think a common usage of InStream might be "read a line" => you usually want to read in e.g. page sized chunks, and then find the newline character.
<andrewrk>
I thought that's what BufferedInStream is for
<daurnimator>
right; so it essentially would be a better replacement for that
<andrewrk>
what makes it better?
<daurnimator>
1. it uses a circular buffer and is more efficient 2. it has a growable buffer
<andrewrk>
1. so let's improve BufferedInStream to be more efficient 2. why is that good?
<daurnimator>
now, compared to OutStream/BufferedOutStream, fifo lets you ask for a slice to write to, and then ".update()" it: in practice i imagine this will be the common usage mode compared to the current OutStream which requires you to pass a slice fully formed
<daurnimator>
andrewrk: 1. fifo is suitable to replace both BufferedInStream and BufferedOutStream: it can hit both "birds with one stone"
<daurnimator>
andrewrk: 2. e.g. imagine you want to read a line in. so you read in a page of data and look for the new line => not found: you probably hit a really long line and need to read in additional pages until you find the newline (buffering the data you have).
<andrewrk>
it sounds like we should do that, then
<andrewrk>
it's tricky to make std lib APIs handle all the use cases correctly; let's do our best
<daurnimator>
andrewrk: agreed. my question was more asking... how far should it go? first thing I have in mind is to try adding .inStream() and .outStream() methods to fifo? that might make at least BufferedOutStream and BufferedInStream removable...
<andrewrk>
it's sort of the end of my day here and so I'm not really thinking clearly about these abstract things. I'll need to read some kind of proposal and mull it over
<daurnimator>
I'm still trying to figure out the best course of action myself
<daurnimator>
But in general, I'm not a fan of how the current stream interfaces get used. e.g. when digging into the elf parser, I found the different seek() and read() streams super weird.
<andrewrk>
I think it helps to always have a concrete use case or two in mind
<andrewrk>
I agree that the current stream interfaces are problematic
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<scientes>
the go streaming API is pretty slick
<scientes>
cause you can kinda just chain them together
<daurnimator>
scientes: "kinda chain them together" => can you explain more?
<daurnimator>
scientes: would you be interested in implementing a "compressing fifo" as a use-case?
<daurnimator>
I imagine that the compression algorithm would prefer certain sized blocks to compress; maybe have alignment concerns?
<scientes>
yeah a byte stream
<scientes>
daurnimator, i think that should be a optimization issue only with the api as simple as possible
<scientes>
and default just buffer
ftxqxd has joined #zig
<andrewrk>
a good rule of thumb is that you should be able to have 2 streams and then pipe one into another, and be able to deal with all the edge cases correctly: backpressure, handling errors, clean closing, pausing and resuming
<daurnimator>
scientes: huh? the fifo here *is* the buffer
<daurnimator>
scientes: `const input = fifo.readableSlice(0)` => gives you a slice into the fifo's buffer: you'd then operate on that; e.g. `compressBlock(input[0..32])` e.g. if your compression algo had a 32 byte "core"
ky0ko has quit [Remote host closed the connection]
<daurnimator>
once done you call `fifo.discard(32)`
plumm has joined #zig
<plumm>
andrewrk: the comptime docs say All function calls cause the compiler to interpret the function at compile-time, emitting a compile error if the function tries to do something that has global run-time side effects. What exactly are global run-time side effects?
<andrewrk>
plumm, for example: calling an external function, inline assembly, writing to the file system, using the network
doublex_ has quit [Read error: Connection reset by peer]
doublex has joined #zig
dantix has quit [Ping timeout: 240 seconds]
chemist69 has quit [Ping timeout: 264 seconds]
chemist69 has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #zig
doublex has joined #zig
dantix has joined #zig
dantix has quit [Ping timeout: 265 seconds]
fsateler has quit [Ping timeout: 240 seconds]
fsateler has joined #zig
_whitelogger has joined #zig
dantix has joined #zig
dantix has quit [Ping timeout: 268 seconds]
dantix has joined #zig
ky0ko has quit [Ping timeout: 245 seconds]
tdc has quit [Quit: Leaving]
knebulae has quit [Read error: Connection reset by peer]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 265 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 268 seconds]
forgot-password has joined #zig
_whitelogger has joined #zig
clktmr has joined #zig
clktmr has quit [Ping timeout: 276 seconds]
<Pistahh_>
hi, is it possible to pass args to the compiled program with "zig build run" ?
Pistahh_ is now known as Pistahh
<dantix>
Usually in this case `-- --args` (e.g `zig build run -- --args`) should do the trick, but I haven't tried it with zig
<Pistahh>
that was the second one I tried (the firstr one was without the --) and it didn't work :)
doublex has quit [Remote host closed the connection]
doublex has joined #zig
lunamn has joined #zig
forgot-password has quit [Ping timeout: 276 seconds]
jjido has joined #zig
protty has joined #zig
knebulae has joined #zig
<protty>
Question for std.event.Loop, does it support treating writing to sockets and reading from sockets as separate streams that can be done in parallel?
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mq32>
protty, it should, as "reading a socket" is the same operation as "reading a file" or more generic "reading any FD"
<mq32>
so if there isn't a special case in std, it should just work
<mq32>
but: i have not looked at the code, just reasoning about a sane implementation
<protty>
it came to mind because theres loop.waitUntilFDReadable/Writable but for the case of epoll: readable & writable could come in the same event and was wondering how it notifies two parallel waitUntils
<mq32>
ah, good question then
<mq32>
and i'm out :D
<mq32>
or well, you can both wait with epoll on a read and write event and you can distinguish those
<protty>
oh, it was in a comment
<mq32>
:)
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<nrdmn>
good evening!
<companion_cube>
oy
<mq32>
hello!
protty has quit [Ping timeout: 260 seconds]
forgot-password has joined #zig
dantix has quit [Quit: Bye]
<andrewrk>
Pistahh, looks like the CLI for zig run regressed. it should be the -- thing as you tried
<Pistahh>
andrewrk: that was with the 0.5.0 arch linux package, I'm just compiling the latest git version to see if that works
<andrewrk>
Pistahh, I think it is regressed in master as well
<Pistahh>
we'll see, I had another issue which I want to test with the latest
<Pistahh>
(I tried to compile something simple and there were a lot of error messages regarding some windows libs. which is weird as it was on linux)
forgot-password has quit [Ping timeout: 240 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 240 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 240 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 240 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 240 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 240 seconds]
doublex has joined #zig
forgot-password has joined #zig
rjtobin has joined #zig
forgot-password has quit [Ping timeout: 268 seconds]
forgot-password has joined #zig
<shakesoda>
is there a documented way to get builder to spit out a header for me, i'm trying to build a library dependency that usually has a generated config.h
<shakesoda>
or if i should just write the file out myself, can i ask it where i should put the thing
forgot-password has quit [Ping timeout: 246 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 268 seconds]
<gonz_>
Is there a currently best set of bindings/layer on top for SDL?