<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
<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>
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 :)
<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]
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
<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...
<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
<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' ""