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/
<zags> Would it make sense for Zig to have a (semi) official std-extensions library? Not std, but many projects would add it as a dependency. This would help focus efforts on large items such as WebSockets, http, tls. Kind of like the boost library. Over time, certain could migrate from std-extensions to std. It would be driven by senior community members.
<zags> So a small and portable std, but also a well-maintained larger library with commonly used features that doesn't fit std.
<zags> It encourages people not to duplicate effort (like 15 http server)
<zags> servers*
<zags> certain things* geez
<fgenesis> oh gosh someone said boost
<zags> it's a big fat life saver
<terinjokes> that might be asking a bit much from where the community and language are
<zags> this is post 1.0
<zags> but having a structure for it to happen earlier would be nice
<g-w1> i think it would make more sense to have a go-to http library that zig endorses
<g-w1> i dont think 1 central library is a good idea
<zags> why not?
<zags> it's proven to help focus effort
<zags> and it requires review and a certain level of quality
<terinjokes> if there's a good http server at satisfies the needs of the community, it will natually be the one the community uses. zig doesn't have to do anything.
<zags> (not thinking about one big library, more like a std-extension repo where people can join efforts to create high quality libraries)
<zags> terinjokes: there's already a tendency to create several half-assed attempts. Like several command line parsers, etc, etc
<terinjokes> and that's a problem because?
<terinjokes> zig is still relatively new, in a lot of causes people are still trying to figure out what zig-like is
<zags> because you end up with low quality, non-maintained libraries
<zags> terinjokes: i'm talking about post-1.0
<zags> not saying std-extensions would be "everything out there", just the main things, like encoding, url parsing, http clienter/server, ...
<zags> boost maintainers never leave because they see it as a priveledge :) and the work is still scrutinized before shipping updates. I think it works great.
<terinjokes> i just see the community building high quality libraries, just like they do in other languages, some of which will be absored into std. i don't think there needs to be an "official" extension
<fgenesis> i'd prefer many small isolated libs that do one thing well over one large behemoths any day
<fgenesis> the fact there exists a tool like bcopy to cleanly copy components out of boost if you don't want the whole thing speaks volumes
<zags> Again, I'm talking about the really core things everybody uses, base64, url parsing, http server. No need to have several of those.
<fgenesis> too. fucking. complicated.
<fgenesis> noody uses base64 and implementing this is 10 lines
<fgenesis> *nobody
<zags> fgenesis: i'm not advocated copying boost the library, only the process, but I think you understood that
<fgenesis> aye
<zags> it would be self-contained, reviewed, maintained core libraries not in std
<zags> that's all
<fgenesis> zpm when :D
<terinjokes> base64 already exists in std anyways
<zags> so bad example
<zags> lots of other examples
<zags> fromHex is not for instance :)
<fgenesis> if this thing ever gets made i vote to call it "booze" just to fuck with everyone
<zags> awww, i was hoping for "zag"
<zags> you zig better with zag
<terinjokes> and std.fmt.hexToBytes exists too
<terinjokes> i know i'm being pedantic
<terinjokes> sorry
<fgenesis> you're good, you're not Wall
<zags> terinjokes: yeah, you seem to miss the point, but you also keep teaching me about the stuff in std so it's all good
ur5us_ has quit [Ping timeout: 264 seconds]
<terinjokes> i don't think i'm missing the point. i just don't think there needs to be a meta project to accomplish your goals of having high-quality libraries
xackus has quit [Read error: Connection reset by peer]
xackus has joined #zig
<zags> situation in other languages says otherwise
<terinjokes> go and rust both have many high-quality libraries
<zags> and also a lot of low-quality libraries
<zags> and lots of duplicate effort
<zags> don't mind that, just senseless for the core stuff everyone needs
<ifreund> pretty sure http in the std is planned for the package manager
<zags> client only right?
<ifreund> in general though, the std will probably get a good bit leaner before 1.0
<ifreund> zags: don't think that's 100% decided yet
<ifreund> though quite possibly, yeah
<zags> alright
<ifreund> there's also the fact that the zig community is intentionally decentralized
<ifreund> I think it would be cool if people chose to organize themselves into maintaing a set of high-quality std-adjacent libraries though
<ifreund> it certianly wouldn't need official support
<terinjokes> all the http servers i've seen in zig so far have already consolidated around one library for http parsing (excepting mine, because that library didn't exist yet)
<zags> that would be ideal, but unlikely to happen without guidance
<ifreund> hzzp?
<ifreund> anyhow, I personally just work on whatever is currently blocking me from doing what I want. So far that's only been wayland related stuff and std contributions
<ifreund> I'll probably branch out more once my compositor is more feature complete
<zags> ifreund: damn you're the guy from showtime
<zags> that was awesome
<ifreund> thanks, I guess zig showtime is my claim to fame :D
<zags> ;)
<ifreund> we've got a zig room for fosdem this weekend by the way, I've got another talk lined up for that about getting rid of all the void pointer casting
<zags> will it be streamed live?
<terinjokes> i missed the notification for that, otherwise I would have dealt with pentabarf again to submit something
<ifreund> I've recorded the talk which will be streamed live on saturday, followed by live q&a
<zags> got a handy link?
<ifreund> ikskuh and kubkon also have cool things to talk about :)
<terinjokes> i'll be tuning in regardless
<zags> nice
Xatenev has joined #zig
zags has quit [Quit: leaving]
Xatenev has quit [Quit: Leaving]
Xatenev has joined #zig
Xatenev has quit [Client Quit]
Xatenev has joined #zig
<viashimo> I have some data in a const array that is not what I expect, and I'm not really sure why. It's not super easy to read, but the first bytes of the '3d vertices' should be non-zero, similar to the 2d vertices: https://paste.debian.net/1184094/
brzg has joined #zig
_whitelogger has joined #zig
_whitelogger has joined #zig
<viashimo> if I switch from packed structs to extern it works
ur5us_ has joined #zig
Xatenev has left #zig ["Leaving"]
kevsmith has joined #zig
gazler_ has joined #zig
<fengb> Probably packed struct bugs
gazler has quit [Ping timeout: 258 seconds]
notzmv has joined #zig
<fengb> Vec3 is probably padded to 16 bytes
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
sebonirc has quit [Quit: sebonirc]
gazler__ has joined #zig
gazler_ has quit [Ping timeout: 276 seconds]
earnestly has quit [Ping timeout: 258 seconds]
brzg has quit [Quit: leaving]
xackus_ has joined #zig
xackus has quit [Ping timeout: 272 seconds]
<geemili> I'm trying to compile some async code for WASM, and I'm getting this error: Stored value type does not match pointer operand type!
ur5us__ has joined #zig
ur5us_ has quit [Ping timeout: 264 seconds]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kevsmith has quit [Ping timeout: 272 seconds]
ur5us__ has quit [Ping timeout: 256 seconds]
notzmv has quit [Remote host closed the connection]
dyeplexer has joined #zig
ur5us__ has joined #zig
terinjokes has quit [Quit: ZNC 1.8.1 - https://znc.in]
terinjokes has joined #zig
ur5us__ has quit [Ping timeout: 264 seconds]
factormystic has quit [Read error: Connection reset by peer]
notzmv has joined #zig
factormystic has joined #zig
Biolunar has quit [Ping timeout: 260 seconds]
Biolunar has joined #zig
_fritchie has quit [Remote host closed the connection]
_fritchie has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
mk12 has joined #zig
texno has joined #zig
mk12 has quit [Quit: Ping timeout (120 seconds)]
jukan_ has quit [Ping timeout: 264 seconds]
gazler_ has joined #zig
gazler__ has quit [Ping timeout: 240 seconds]
decentpenguin has quit [Quit: ZNC crashed or something]
cole-h has quit [Ping timeout: 265 seconds]
decentpenguin has joined #zig
tnorth_ has joined #zig
maier has joined #zig
jukan has joined #zig
mikdusan1 has quit [Ping timeout: 258 seconds]
mtiljeset[m] has joined #zig
mikdusan has joined #zig
maier has quit [Quit: Lost terminal]
sord937 has joined #zig
factormystic3 has joined #zig
factormystic has quit [Ping timeout: 276 seconds]
factormystic3 is now known as factormystic
ex_nihilo has joined #zig
gpanders has quit [Ping timeout: 240 seconds]
gpanders has joined #zig
earnestly has joined #zig
ur5us__ has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
mmurd has quit [Ping timeout: 260 seconds]
mmurd has joined #zig
cow-orker has quit [Quit: Lost terminal]
ur5us has joined #zig
ur5us__ has quit [Ping timeout: 264 seconds]
zags has joined #zig
<zags> |*item| what's the star here called language-spec wise? The docs seems to indicate a reference, but it doesn't say what a reference actually is.
<zags> is it more like "give me a pointer to that item" ?
<daurnimator> zags: yep
<zags> alright, in that case, why isn't the syntax |&item| ? The *item looks like dereferencing and Zig uses & to get the address elsewhere
<daurnimator> fair question. I don't think that syntax has been proposed for it before
<daurnimator> I think `|*const item|` is also valid
ur5us has quit [Ping timeout: 264 seconds]
<zags> I see, feels like it should be & but may be missing something
<ifreund> don't think |*const item| is a thing
<daurnimator> zags: I remember when learning zig `|captures|` was very undocumented in the manual. I think I checked a few weeks ago and it was still missing
<ifreund> it's demonstated in the for and while loop examples iirc
cow-orker has joined #zig
<zags> right, docs will be fixed, but it just weird to have a dereference-like syntax for getting the address
<zags> s/address/pointer to
<ifreund> dereference is foo.* though
<daurnimator> zags: when reading zig, I read `*` as "a pointer to"
<ifreund> this is more like declaring a variable as a pointer than taking the address of something
<zags> ifreund: yes, but it's still * for dereference and & pointer-to elsewhere
<zags> and C programmers are used to *item as dereference
<zags> *item just looks wrong on multiple levels :)
<ifreund> *i32 in zig is a pointer to i32
<ifreund> &i32 is not a type
<daurnimator> e.g. `const foo: *T` I read as "the constant foo is of type a pointer to T"
<zags> but item is not a type
<daurnimator> zags: yeah its a good point
haliucinas has quit [Read error: Connection reset by peer]
haliucinas has joined #zig
amk has quit [Remote host closed the connection]
amk has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
<ifreund> andrewrk: I'm poking at array initialization for the zig fmt refactor by the way, just letting you know to hopefully avoid duplicated work
dreda has joined #zig
<dch> in CMakeLists.txt, here https://github.com/ziglang/zig/blob/master/CMakeLists.txt#L30 is this overridable from a `cmake -DZIG_VERSION=...` ?
<dch> when building from the latest tarball, I'm ending up only with 0.8.0 in `zig version`
<ifreund> dch: it should be something like 0.8.0-dev.1071+7069459a7 for master builds
<ifreund> at least that's what I get building from the git repo
<dch> exactly
<ifreund> I guess when building from the tarball there is no git history...
<dch> ifreund: I only get that when building from git, though, so the tarball doesn't have the git goodness
<dch> OK this does what I want, `cmake -G Ninja . -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=/usr/local/llvm11 -DCMAKE_INSTALL_PREFIX=(pwd -P)/release -DZIG_VERSION="0.8.0-dev.1120+300ebbd56" -DZIG_STATIC=ON`
<ifreund> nice, you packing zig for something?
<ifreund> *packaging
<dch> yep, it's the last piece for having a lang/zig-devel in freebsd ports that I update every few days. also I can easily test my sh*t against latest zig to keep track on whats changing
<ifreund> nice :)
<ifreund> I wonder if river builds on freebsd currently, that would be good to test before a first release...
<dch> ifreund: it's already in ports, https://www.freshports.org/x11-wm/river jbeich is looking after it
<dch> updated yesterday, but presumably still using zig 0.7.1
<ifreund> oh sick, I love jbeich
<ifreund> I should probably set up freebsd CI to make sure I don't break it
<dch> I've not met him, but maybe this year we have a euroBSDcon again
<ifreund> I don't know him really, I just see him pop up everywhere packing wayland stuff and fixing freebsd compat issues
<dch> he's a compiler-patching daemon
factormystic2 has joined #zig
<zags> compiler greeted me with "error: TODO implement inferred return types" but 447 is closed :)
factormystic has quit [Ping timeout: 276 seconds]
factormystic2 is now known as factormystic
<ifreund> heh
<zags> what am I missing? :)
<ifreund> zags: might work if you declared your accumulator argument to be anytype
<zags> ifreund: using what return type?
<zags> oh, you mean anytype instead of function signature?
<ifreund> yeah
<zags> oh yeah, and I guess I can add some compile-time checks so the signature makes sense and give a nice error message if not
<zags> that'll work, thanks
<ifreund> no problem!
<zags> does std have any of these <algorithm> like functions?
<zags> i'd like to accumulate, filter, map, fold, zip, etc
<ifreund> nope
<zags> and no library out there for it? guess i'll write something then :)
<ifreund> go for it!
<zags> it's maddening that comptime_int doesn't coerce to type that it obviously fit in
<ifreund> it does?
<g-w1> I think it is a bigint right?
<zags> yeah, but I feel like I should be able to write
<zags> std.testing.expectEqual(120, accumulate(@as(u64,1), list, mul));
<zags> when the type of the second argument is u64 and 120 clearly fits
<zags> instead I have to sprinkle test code with mindless @as(f64, x) tests
<ifreund> that's because the of the signature of expectEqual()
<ifreund> if it took a concrete type instead of anytype it would corecer without the @as()
<zags> i understand there are reasons, still maddening :D
<ifreund> for example, (though this is improper usage) std.testing.expectEqual(accumulate(@as(u64,1), 120, list, mul));
<zags> i'm reversing order of args, but it's less readable, i like the constants first
<zags> std.testing.expectEqual(accumulate(@as(f64,1), list, mul), 150); works, because, as you say, of the signature of expectEqual
<ifreund> putting the expected result first is also the proper way to use this api
<ifreund> my example was just to demonstate why the @as() was required here
<ifreund> I don't like this testing API either fwiw, @as() everywhere is ugly
<zags> aye
<zags> a 5u64 postfix syntax would be another option
<ifreund> I think that would be unlikely to be accepted for reasons of orthagonality
<zags> it could be accepted for reasons of pragmatism :)
<zags> orthagonality and generality isn't always the right choice
donniewest1 has joined #zig
vcarvalho has joined #zig
kchambers has joined #zig
factormystic has quit [Read error: Connection reset by peer]
<zags> decided to write up the discussion points, https://bit.ly/3cG7RzP :)
ex_nihilo has quit [Ping timeout: 264 seconds]
<g-w1> why is scoping in while loops a danger?
<g-w1> there is no variable shadowing
<zags> variable reuse
<zags> it's why c99 got it
<zags> (init decl)
<g-w1> that doesn't cause bugs though
<zags> yeah it does
<g-w1> how
<zags> because you refactor and start off with a new while (i < 0) and it compiles because there's an existing i in scope which you just forgot to reinitialize
<zags> having an init-clause naturally makes you declare a scoped counter
<zags> others also mentioned having seen bugs because of it when it was discussed earlier
<g-w1> ok
<fengb> I don't think I've ever encountered a bug with reinitialize
<zags> Others have, I think unnecessary pollution of outer scope is obviously a bad idea
<zags> how does "accumulate(1, list, (a,b) => a*b)" look under that proposal?
<fengb> accumulate(1, list, fn (a,b) { return a * b; })
<fengb> Er... fn (a: T, b: T)
<zags> I see, probably good, I'll updte with a link to the issue - thanks
<fengb> No closure captures though, that would require some automatic lifetime management
koakuma has quit [Quit: Leaving.]
<zags> yep
<fengb> There's a macro proposal for limited scoped "closures": https://github.com/ziglang/zig/issues/6965
ex_nihilo has joined #zig
jukan has quit [Ping timeout: 276 seconds]
ziguana[m] has quit [Quit: Idle for 30+ days]
ifreund_ has quit [Quit: Idle for 30+ days]
<zags> fengb: that looks v nice
nvmd has quit [Quit: Later nerds.]
Akuli has joined #zig
waleee-cl has joined #zig
tnorth_ has quit [Ping timeout: 258 seconds]
nvmd has joined #zig
<Snektron> nice writeup, agree with most of the points
<mikdusan> kinda like ruby trailing blocks
<fengb> We should name them something other than macros
<fengb> Cause then we can't keep saying we don't have macros
<mikdusan> i know right
zags has quit [Ping timeout: 256 seconds]
<ifreund> stack captures
<companion_cube> ruby blocks would still be nicer
<companion_cube> better power-to-weight ratio for closures that never survive the stack frame
<ifreund> keyword could be just capture
<companion_cube> (well this looks like blocks, but without the ability to state `break`? or would it?)
<mikdusan> i'd rather keyword `block` over `macro`
<fengb> But we already have blocks
kbd has joined #zig
hnOsmium0001 has joined #zig
a_chou has joined #zig
cole-h has joined #zig
jukan has joined #zig
<companion_cube> not the same blocks
<companion_cube> (I mean, unless current blocks are already parametrized?)
<fengb> No, but the name is taken ;)
<mikdusan> but the keyword is not :P
<mikdusan> not all blocks are stack-local-functions (frame functions?) but when they are, we use the keyword block
<mikdusan> strictly speaking does #6965 allow for no-captures and no-params?
<companion_cube> better than frame functions!
<companion_cube> frame coroutines :)
<companion_cube> at least in crystal (and ruby I guess)
<companion_cube> the function that takes a block as argument (e.g. `foreach`) calls `yield` to pass stuff to the block
<companion_cube> which can therefore have internal state preserved between yields
<companion_cube> and conversely the block can break/return/continue (and try)
<ifreund> woot! found the parser bug that had me stuck for an hour
<mikdusan> and who says a little bike shedding on the side doesn't yield results?
<ifreund> well I'm working on andrewrk's ast refactor branch so I'm not sure this counts as bikeshedding
<mikdusan> no i mean this block keyword thingee is the bike shedding and it made you productive on the parser :)
<ifreund> heh :D
<fengb> Lets call it a bikeshed
<mikdusan> ftw
zags has joined #zig
sord937 has quit [Ping timeout: 268 seconds]
sord937 has joined #zig
dyeplexer has quit [Remote host closed the connection]
vcarvalho has quit [Quit: WeeChat 2.9]
<andrewrk> ifreund, I hope we picked test cases that don't conflict!
<andrewrk> I'm on container decls right now ( struct{}, union(enum){}, etc)
<g-w1> any idea why this is tripping? ../src/zig_llvm.cpp:1175:1: error: static_assert failed due to requirement '(llvm::Triple::ArchType)ZigLLVM_hexagon == Triple::hexagon' ""
<g-w1> static_assert((Triple::ArchType)ZigLLVM_hexagon == Triple::hexagon, "");
<g-w1> asking for #7961
kchambers has quit [Quit: WeeChat 3.0]
<andrewrk> g-w1, it means compiling against a patched or wrong version of LLVM
<g-w1> thats what I thought
<andrewrk> that static assert protects our enums in the corresponding .h file because we need the enum items to match
<andrewrk> ifreund, oh I see you told me you picked array initialization. thanks! :)
<ifreund> andrewrk: Yeah, PR's already up for that, I'm looking at ArrayType and ArrayTypeSentinel next
<andrewrk> nice work and thank you very much
<ifreund> no problem, helping to get self-hosted feature complete is in my best interests :D
<ifreund> andrewrk: put up another PR for array types, I don't think I understand how comments should be rendered though
<andrewrk> oh yeah I think I left that as a TODO for myself inside renderToken, don't worry about it
<andrewrk> if you pick up another test case, lmk which one so we don't conflict - I'm still on container decls
<ifreund> I added some TODOs for comments in struct/array init since they'll need special handling for comments
<ifreund> andrewrk: will do, I'm gonna cook some food first though
<andrewrk> cool cool
wootehfoot has joined #zig
frett27_ has joined #zig
frett27 has joined #zig
jukan has quit [Ping timeout: 256 seconds]
cole-h has quit [Ping timeout: 240 seconds]
frett27_ has quit [Ping timeout: 272 seconds]
frett27 has quit [Ping timeout: 272 seconds]
<ifreund> andrewrk: I think I'm going to start on pointer types now
<andrewrk> ok
geemili has quit [Ping timeout: 258 seconds]
<dvaun> ooh I just saw that Zig has a devroom at fosdem
<ifreund> indeed :)
<dvaun> Ah you're giving the talk on Zig and wayland? Cool :) depending on the schedule with my family I may attend
<zags> waycool
jukan has joined #zig
<ifreund> :D
jukan has quit [Read error: Connection reset by peer]
jukan has joined #zig
<dvaun> Ah, I see it'll be ~4:45am UTC-8
craigo has joined #zig
<ifreund> should be recorded if you don't feel like being awake at 4:45 :D
sord937 has quit [Quit: sord937]
chrismills has joined #zig
chrismills has quit [Quit: Connection closed]
Akuli has quit [Quit: Leaving]
midgard has quit [Read error: Connection reset by peer]
midgard has joined #zig
<ifreund> andrewrk: got distracted but back at work now. I'm not sure I understand your intention with the PtrType tags though, it seems like they aren't granular enough: https://github.com/ziglang/zig/blob/0f3fa4d6540af42552571bf46609ab5546c16b72/lib/std/zig/ast.zig#L1507
<andrewrk> which syntax for example?
<ifreund> how do I tell if a node with tag PtrTypeAligned is a pointer-to-one or a pointer-to-many?
<andrewrk> poke around in the token_tags array
<ifreund> ah right, thanks
<andrewrk> one of my realizations was that we only need sub expressions when the tree structure would prevent that from working
<andrewrk> have a look at the ast.zig code for var decls which does a bit of poking around and finding other keywords
<ifreund> Yeah I see how to do it now, I just forgot I can poke around at the tokens
<andrewrk> I'm getting close with ContainerDecl btw
<ifreund> cool :)
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
a_chou has quit [Remote host closed the connection]
donniewest1 has quit [Quit: WeeChat 3.0.1]
donniewest1 has joined #zig
<andrewrk> ifreund, done. I'm taking a lunch break, will make note of which one when I start another test case
<andrewrk> there might be some minor conflicts, but they should be easy to resolve I think
<andrewrk> fixed a firstToken bug with .Comptime too
kevasmith has joined #zig
sebonirc has joined #zig
<ifreund> cool, I'll rebase real quick before I write more code
donniewest1 has quit [Client Quit]
sebonirc has quit [Ping timeout: 276 seconds]
sebonirc has joined #zig
xackus_ has quit [Ping timeout: 264 seconds]
zags has quit [Quit: leaving]
kbd has joined #zig
wootehfoot has quit [Ping timeout: 256 seconds]
ifreund_ has joined #zig