waleee-cl has quit [Quit: Connection closed for inactivity]
hiljusti has quit [Ping timeout: 260 seconds]
nvmd has joined #zig
ur5us has quit [Ping timeout: 250 seconds]
drp has joined #zig
earnestly has quit [Ping timeout: 265 seconds]
ur5us has joined #zig
squeek502 has quit [Remote host closed the connection]
ncon has quit [Ping timeout: 268 seconds]
ncon has joined #zig
zenkuro has quit [Ping timeout: 246 seconds]
tuplestruct has joined #zig
leon-p has joined #zig
earnestly has joined #zig
ur5us has quit [Ping timeout: 250 seconds]
adamkowalski has joined #zig
<adamkowalski>
Is there a way to build out a switch statement given an enum using meta programming
<adamkowalski>
For example if you wanted to print out the value of the enum as a string
<adamkowalski>
I don't want to actually list all the branches of the switch, I want to generate each branch and say that if the branch gets chosen just write the enum value to stdout
bollu has quit [Remote host closed the connection]
isolier has quit [Quit: Ping timeout (120 seconds)]
<ifreund>
daurnimator: any more input on ttps://github.com/ziglang/zig/pull/8698 ? do len()/span() work for your use-case?
tefter has joined #zig
tefter_ has joined #zig
tefter has quit [Remote host closed the connection]
tefter__ has quit [Ping timeout: 260 seconds]
<daurnimator>
ifreund: the problem with len() is that it always trusts sentineled slices rather than finding the sentinel
<ifreund>
daurnimator: to be honest, I haven't seen a use-case where such behavior is required on a sentinel terminated slice/array that wasn't subtly buggy yet
<ifreund>
do you have a concrete example?
<daurnimator>
ifreund: sockaddr_un.sun_path ?
<ifreund>
daurnimator: that should be a plain array, not seninel terminated
<ifreund>
if it is sentinel terminated, that's a bug
<daurnimator>
heh; you're wrong but also right: according to the spec its null terminated; but linux gets it wrong in certain circumstances so you can't count on it
<daurnimator>
let me think for a minute :P
<ifreund>
daurnimator: null terminated in C means there is a 0 *somewhere* in the array, not necessarily at the end
<ifreund>
if there is not one at the end and you use a 0 terminated array type, that is Illegal behavior in zig
<ifreund>
s/means/usually means/ I'm sure there are exceptions
<daurnimator>
a lot of C libraries put a null after all arrays just to be safe
<ifreund>
Which is exactly why I started this pull request in the first place
<ifreund>
daurnimator: yes you're right, but we can't rely on that
<daurnimator>
we can't rely on it universally; but for the libraries that do: lenZ is the right function for it
<ifreund>
C's type system is not strong enough to statically ensure there is a 0 at the end
<daurnimator>
the type system isn't; but libraries document it
<ifreund>
fair, though scanZ() will work exactly the same as the current lenZ()/spanZ() for 0 terminated arrays/slices
<ifreund>
the only difference is that it requires them to be 0 terminated
<daurnimator>
true for 0 terminated.
<ifreund>
The use-case my PR doesn't currently support is sentinel terminated arrays/slices with a non 0 sentinel
<ifreund>
in the case that iteration should always occur
TheLemonMan has joined #zig
<TheLemonMan>
mikdusan, I finally found where the i386 problem is... we're specifying the c library components in the wrong order
<TheLemonMan>
clang uses -lm -lpthread -lc while we use -lc -lm -lpthread
<ifreund>
... that matters?
<TheLemonMan>
yeah, especially since our stubs are a bit wrong (#8714)
<TheLemonMan>
the link order changes the lookup order used by ldso
<daurnimator>
ifreund: yes link order matters
<ifreund>
I guess glibc doesn't do what musl does and put everything in the same so
<daurnimator>
ifreund: so yeah I guess the new function works for the 0 sentinel....... though it seems less generic to me.
<ifreund>
daurnimator: you're right that it's less generic, but it has to be to work properly for non-sentinel terminated arrays/slices
<TheLemonMan>
yeah, musl takes a pragmatic approach
<ifreund>
which are the correct type to use in many cases when interfacing with an array from C containing a sentinel terminated string
ur5us has quit [Ping timeout: 250 seconds]
<daurnimator>
ifreund: are you refering to `[*c]` pointers?
<ifreund>
I'm refering to C struct containing an array which is known to hold a 0 terminated string
<daurnimator>
or just arrays?
<ifreund>
when binding this you have to use a non-sentinel terminated array type unless the library makes some explicit gaurentee that they will put a 0 in the last slot of the array in all cases
<daurnimator>
for arrays you'd currently need to do: `spanZ(@ptrCast([*:0]T, &myarray)`... but I guess that loses the safety on length?
<ifreund>
yep
<daurnimator>
though actually `scanLenZ` doesn't have length safety either
<daurnimator>
(and it's not only safety: it's an optimization too)
<daurnimator>
okay in that case I think `scanSentinel` with the signature you've suggested works.
<daurnimator>
though please make it length-safe?
<ifreund>
daurnimator: it is length safe right now for non-sentinel terminated types
<ifreund>
actually for all types
<ifreund>
*all types for which the length is known
tefter has joined #zig
<ifreund>
daurnimator: I'd like to have scanZ() as well as an alias for scanSentinel(ptr, 0)
xackus__ has joined #zig
<mikdusan>
TheLemonMan: nice!
<mikdusan>
it's sad there are so many linking differences
<daurnimator>
ifreund: mmmmm, I dunno about the alias... the explictness seems nice
tefter_ has quit [Ping timeout: 240 seconds]
<daurnimator>
ifreund: in `scanSentinel` there is also no need/want to assert that the sentinel on the array/slice matches the one passed
hiljusti has joined #zig
<TheLemonMan>
the real question is: why the produced binaries are correctly loading on my system despite the library order being wrong?
<TheLemonMan>
the difference between ubuntu and debian should be minimal (or none at all)
<daurnimator>
TheLemonMan: because glibc has moved symbols between libraries and not kept everything up to date?
<mikdusan>
when in wrong order, is there a buildtime or linktime error? or just bad runtime
<TheLemonMan>
daurnimator, I've double-checked and both systems show the same symbols at the same places
<TheLemonMan>
mikdusan, ld.so tries to find a match in the other .so deps
<daurnimator>
TheLemonMan: hmmm. do they have constructors at all?
<mikdusan>
oh noes csu stuff :)
<TheLemonMan>
but on the ci system the lookup fails right after hitting libc.so.6, only for that symbol
<TheLemonMan>
daurnimator, don't think so
<daurnimator>
TheLemonMan: otherwise you might be hitting the neverending pain of dynamically linking libpthread that we used to have in lua
<daurnimator>
a lot of glibc internals do one thing if libpthread is unloaded; and another if libpthread is loaded.
<TheLemonMan>
yeah that suuucks
<mikdusan>
so yeah is it that if there is no libpthread, then single-threaded, otherwise it NEEDS to find the symb from pthread to be multi?
<daurnimator>
mikdusan: yeah... and some things incorrectly cache the face that libpthread is unloaded
<mikdusan>
linker games. It's a TV show
<daurnimator>
or at least they did 5 years ago
<daurnimator>
and we went on a bug reporting spree
<mikdusan>
5 years ain't long enough. Andrew tweaked x86_64 baseline to x86_64_v2 and in about 3 minutes there were issue reports. And that's 10 years ago cpu stuff.
<ifreund>
TheLemonMan: no problem, changes looked nice and straightforward and it fixes that CI failure :)
<daurnimator>
though it appears even bugs with acks have that
<daurnimator>
so I guess glibc doesn't use the status field
<TheLemonMan>
I've never checked if the native libc detection feature works for multilibs
<ifreund>
daurnimator: I think there is a need to assert that the sentinel in the type matches the one passed, otherwise we can't return a sentinel-terminated slice of the right type
<mikdusan>
i don't think it does; I've seen no support for more than more crtlib dir
<mikdusan>
err wait side issue
<daurnimator>
ifreund: what if I want to find a span until the first ' ' in a null-terminated array?
<ifreund>
daurnimator: do you expect the return type to be []T or [:' ']T ?
<ifreund>
I guess we could actually do the latter if we make the sentinel arg comptime
<TheLemonMan>
ah right, it only works for native targets
<mikdusan>
one thing to watch out for is we don't support > 1 crtlib dir. and some platforms need that like dragonfly. I wonder if all linux distros just need 1 as long as you identify the correct multilib
<mikdusan>
hmm yeah alpinelinux sticks out. it has /usr/lib/ for most csu objects. but then crtbegin/crtend pair is a compiler-provided thing so it's found in another path
<daurnimator>
ifreund: in that case, `[:' ']u8`, and yeah, I was thinking the sentinel would be a comptime argument
<ifreund>
daurnimator: the problem is that if the sentinel is not found in the length of the array/slice, we can't safely return a slice terminated with sentinel that wasn't found
<daurnimator>
good point
<ifreund>
I think your use case should be supported by scanSentinel(@as([]T, ptr), ' ') instead
<daurnimator>
in that case its just a []u8 return value and it doesn't have to be comptime known
<ifreund>
daurnimator: I think that in the cases where the sentinel is part of the type retunrning a sentinel terminated slice can be much more convienient
<ifreund>
always returning []T or []const T would be simpler though
<daurnimator>
ifreund: hmm okay.... so I guess if the sentinel matches that of the slice/array; then you use a more specific type; otherwise the plain slice
<ifreund>
yep that's my plan, which means we do need to require the sentinel passed to match that of the type if the type is sentinel terminated
<ifreund>
oh wait, didn't read carefully enough
<ifreund>
yeah we can support both use
<ifreund>
just need to make the return type a bit more complex
<daurnimator>
yeah
<ifreund>
cool, thanks for bouncing ideas with me on this
<daurnimator>
I like that this sort of gives us `split(s, ',', 1)`
<daurnimator>
so compare with psuedo-python
<ifreund>
daurnimator: what do you think of spanTo() as an alternative name?
tefter has quit [Ping timeout: 265 seconds]
tefter has joined #zig
<daurnimator>
ifreund: sliceTo?
<daurnimator>
sliceNotIncluding
<mq32>
sliceTerminatedBy
<earnestly>
(notincluding => excluding)
<ifreund>
I was trying to come up with something a little shorter/sweeter without losing accuracy
<ifreund>
I like sliceTo()
<earnestly>
Is this strchr?
<ifreund>
earnestly: pretty much, but returning a slice instead and with a much fancier type system
<earnestly>
Of course
<earnestly>
sliceto seems fine to describe that concept
<earnestly>
Although 'to' often denotes conversion of some sort
<ifreund>
this returns a slice from the start of the passed slice to the first occurence of the given element, not including that element
<earnestly>
Yeah, the documentation can mention the non-inclusive nature of the range, it doesn't necessarily have to be part of the name unless you are going to add inclusive ranges
<ifreund>
the signature will be `pub fn sliceTo(ptr: anytype, end: meta.Child(@TypeOf(ptr))) SliceTo(ptr, end)`
<ifreund>
and there will be a hefty doc comment explaining what it does for a wide variety of types
<earnestly>
vim has this motion with 't' and 'f' where the typical mnemonic is 't'o and 'f'ollowing
<earnestly>
You also have 'until'
<ifreund>
yep, so does kakoune
<earnestly>
And the word until is non-inclusive by definition, which is nice
zenkuro has quit [Ping timeout: 240 seconds]
<ifreund>
I'm not sure it is tbh
<earnestly>
sliceUpTo sliceUntil
zenkuro has joined #zig
<ifreund>
UpTo also isn't unambigously non-inclusice IMO
<mq32>
takeUntil ?
<earnestly>
sliceTill
<ifreund>
I think sliceTo() with a good doc comment is the right way to go here
<earnestly>
Toward heh
<ifreund>
one nice feature of this new API is that we no longer assume [*c] pointers are all 0 terminated
<earnestly>
How does it determine the length (do you pass it in?)
<ifreund>
it always iterates
<earnestly>
mq32: take is nice in that it has prior art
<earnestly>
ifreund: How does it know when to stop iterating?
<ifreund>
when it finds `end` or if the passed ptr type has a known max length it stops there
<earnestly>
Okay, that makes sense
<mikdusan>
libc uname() is hot garbage wrt bufsize
<TheLemonMan>
but it only takes a pointer
<mikdusan>
the fields are potiners to hard-coded bufsize for each
<earnestly>
That sounds perfect
<earnestly>
Why would you not want hardcoded buffer sizes?
<mikdusan>
is that a real question?
<earnestly>
Would you prefer dynamic memory allocation for each struct member?
<mikdusan>
to add uname() to std.os for zig,
<mikdusan>
I need to give it a struct. the struct has pointers to a buf for each member,
<mikdusan>
how do I know how big to make each member
<earnestly>
_UTSNAME_*_LENGTH
<earnestly>
glibc defines this as: #define _UTSNAME_LENGTH 65
<earnestly>
And uses it for each member
<ifreund>
mikdusan: isn't this a struct of arrays not a struct of pointers?
<earnestly>
Yes
<earnestly>
char sysname[65]; essentially
<ifreund>
which is exactly what musl does of course :D
<mikdusan>
whcih is exactly what *bsd doesn't use of course
<ifreund>
:/
<mikdusan>
i can hard code this just like our linux std.os does, but how in the fuck am I supposed to find out if this is stable for older versions of each os
<ifreund>
mikdusan: this should just go in std.os.bits.linux or equivalent no?
<mikdusan>
here's a snip from linux manpage:
<mikdusan>
> The length of the fields in the struct varies.
<mikdusan>
> Some operating systems or libraries use a hardcoded 9 or 33 or 65 or 257.
<mikdusan>
> Other systems use SYS_NMLN or _SYS_NMLN or UTSLEN or _UTSNAME_LENGTH.
<mikdusan>
> Clearly, it is a bad idea to use any of these constants; just use sizeof(...).
<mikdusan>
> Often 257 is chosen in order to have room for an internet hostname
<mikdusan>
. hot. garbage.
<TheLemonMan>
don't use uname them heh
<mikdusan>
exactly
<TheLemonMan>
*BSDs offer most of that info via sysctl
<TheLemonMan>
#6600 is also about this, we don't really care about uname() and its historical quirks
<mikdusan>
yeah I was being lazy. last one I am updating version detect is openbsd and it doesn't have sysctlbyname just sysctl. looks like that's still better than uname
<TheLemonMan>
we only care about getting *whatever uname returns* to the user
<mikdusan>
just throw out slices altogether. to hell with them
<daurnimator>
I have once had a really good use-case for VLAs
<daurnimator>
or I should say: a really good use-case for alloca
<mikdusan>
oh you mean stack vla thingees?
<daurnimator>
*once*
<earnestly>
How do you solve the inherent gets-like problem they have?
<earnestly>
(Or was it just 'hope')
<daurnimator>
earnestly: the use-case was related to UDP: udp packets have a small enough max size
<earnestly>
mikdusan: (VLAIS)
<earnestly>
So hope :p
<daurnimator>
i.e. an absolute max of 65536 bytes; in any actual situation a max of 9000 (over ethernet jumbo frames); in normal situation 1300 bytes or so.
m314 has quit [Quit: Konversation terminated!]
<daurnimator>
the point of a VLA there is you don't want to use up >65536 bytes of stack in every frame that deals with UDP packets.
<daurnimator>
==> it's terrible for performance
<daurnimator>
anyway; that was the one genuine use-case for alloca/VLAs that I ever had.
<mikdusan>
yeah 64 KiB is like L1 cache size on cpus these days
<mq32>
mikdusan: even if you allocate a VLA that size, you're not even using the full cache
<mq32>
unless you fully use the memory, but then your cache will be invalidated either way
<mikdusan>
oh yeah you're right
<mikdusan>
so basically it's a stack-size limit killer
hiljusti has quit [Ping timeout: 260 seconds]
Guest84063 has joined #zig
<ifreund>
TheLemonMan: looks like we need -ldl as well as -lpthread when using the native libc, I wonder how many more there are...
<ifreund>
do you know where that one should be placed in the linking order?
<TheLemonMan>
ifreund, ahh, that was my biggest fear
<TheLemonMan>
I think we should match what's done for the cross-compilation case then and link all the libs in glibc.libs (except for "ld")
<ifreund>
makes sense to me, shall I do that in my PR?
<TheLemonMan>
yeah, you may want to cherry-pick 2bb8e1f from #8705
<TheLemonMan>
that fixes the linking order
<ifreund>
ah sweet
<daurnimator>
TheLemonMan: leave out -lcrypt if you can
<ifreund>
daurnimator: there is no crypt in glibc.libs :)
<TheLemonMan>
now some qemu-ppc test case is failing, nice
Guest84063 is now known as ntzmv
<daurnimator>
ifreund: depends when :p
<TheLemonMan>
no implicit -lcrypt, if the user specifies that on the command line we're forced to link that in heh
ntzmv is now known as notzmv
<daurnimator>
but only sometimes
<mikdusan>
so... trying to comptime'ize system libc linking logic for variuos linux distros? 😬
<TheLemonMan>
and of course I can't reproduce the crash locally
<mikdusan>
curious what is your local linux distro
<TheLemonMan>
debian bullseye
<TheLemonMan>
ah fuck, the new test runner tricked me
<TheLemonMan>
there's one failing test but it won't tell you which one
lemmi has quit [Ping timeout: 240 seconds]
<TheLemonMan>
but I also have a job interview to prepare for, let's put this on the backburner for a while
<ifreund>
good luck!
<TheLemonMan>
thank you!
novakane has quit [Ping timeout: 252 seconds]
novakane has joined #zig
<ifreund>
great, it looks like LibCInstallation.findNative() is broken on macos/arm64
jokoon has joined #zig
Anzh has joined #zig
cole-h has joined #zig
bollu has joined #zig
zenkuro has quit [Ping timeout: 252 seconds]
zenkuro has joined #zig
lemmi has joined #zig
B767B has joined #zig
TheLemonMan has quit [Read error: Connection reset by peer]
waleee-cl has joined #zig
<mikdusan>
semarie: re #8741, "unused". Do you mean the pseudo-constants like MAX, or do you mean ones that we don't use/ref in .zig code?
TheLemonMan has joined #zig
<semarie>
mikdusan: for me it is the ones that we don't use/ref in .zig
<semarie>
but I could understand people could wants them (even if zig simplifies things with @cInclude())
<semarie>
so if it is very important to provide all of them, at least don't include MAX
aerona has joined #zig
leon-p has quit [Ping timeout: 252 seconds]
leon-p has joined #zig
carsme has quit [Quit: carsme]
hiljusti has joined #zig
<andrewrk>
ifreund, ha, look at Daniel Micay's response to that, which is basically following my same reasoning to "comptime"
notzmv has quit [Ping timeout: 240 seconds]
<ifreund>
andrewrk: yeah, I had this same complaint with every language until I found zig :D
<andrewrk>
TheLemonMan, oof yeah no stack traces from tests, I'll address this right away
<earnestly>
ifreund: Ah, he pretty much single handidly killed off green threads in rust and moved it into a high performance focused language lol
<andrewrk>
ooh 8705 looks tasty
<andrewrk>
#1923 was easy, lol. should have done this years ago
<ifreund>
sweet
<earnestly>
ifreund: You've reminded me about a few things and I wonder; how does zig relate to llvm and noalias? I remember this being a constant problem in rust (apparently due to requirements on C restrict). Does zig bypass this (especially when/if zig has its own cbe)?
sord937 has quit [Quit: sord937]
<TheLemonMan>
andrewrk, #1923 in stage1 or stage2?
<earnestly>
> Hitting issues of C being miscompiled leads to needing to figure out if the standard allows the compiler to be broken, which it probably does, so WONTFIX.
<earnestly>
heh
<andrewrk>
TheLemonMan, stage1
<TheLemonMan>
noice
notzmv has joined #zig
jokoon has quit [Quit: Leaving]
<andrewrk>
ehhh turned out to not be so trivial
<andrewrk>
forgot I wanted to change how `catch` works too
<andrewrk>
anyway with the last 2 commits we're in an OK place. it prints an error return trace, which may have some unhelpful entries at the beginning, but if you scroll down, the good stuff will be there
notzmv has joined #zig
<ifreund>
so just like pretty much any other error return trace in a non-trivial project currently :P
tefter has quit [Quit: WeeChat 3.1]
tefter has joined #zig
<TheLemonMan>
ifreund, if you want to dig deeper into the mess that is libc linking have a look at is_libc_lib_name (wrong case?) and how it's used
powerofzero has joined #zig
<powerofzero>
Is there a way to make zig-test use the tty as stderr instead of capturing it in the tests?
<ifreund>
TheLemonMan: heh, yeah why is that snake_case. Is there any major issue with that right now though?
powerofzero has quit [Read error: Connection reset by peer]
<TheLemonMan>
that function is used by the frontend to drop any component that's part of the default set of linked-in libs
<TheLemonMan>
it has some extra entries tho, that may be a problem (?)
<TheLemonMan>
your PR reminded me of that and #7796
<ifreund>
TheLemonMan: indeed, -lcrypt, -lnet, and -lresolv will get silently ignored
leon-p has quit [Quit: leaving]
<TheLemonMan>
and update_glibc.zig is not producing any stub for those
[wtf] has quit [Ping timeout: 265 seconds]
jmiven has quit [Quit: bye]
jmiven has joined #zig
jokoon has joined #zig
aerona_ has joined #zig
<andrewrk>
TheLemonMan, the patch to glibc sysdep.h, is that fixed upstream?
<TheLemonMan>
yep, the sysdeps folder contents we ship are quite oold
<andrewrk>
gotcha
aerona has quit [Ping timeout: 276 seconds]
novakane has quit [Ping timeout: 265 seconds]
mokafolio has quit [Quit: Bye Bye!]
B767B has quit [Remote host closed the connection]
mokafolio has joined #zig
<ifreund>
I love the magic of git rebase when used properly. I had cherry-picked one of TheLemonMan's commits from his PR that just got merged, but git rebase on to master had no conflicts and just worked :)
<mikdusan>
reset, rebase, cherry-pick. there is nothing else
<noam>
lol
<ifreund>
throw in fetch and that's really all you need
<noam>
bisect is also tremendously useful
<noam>
Though it kinda requires good commit hygiene
<noam>
I ended up having to restructure the history of a branch to narrow its results down from "15 possible bad commits" lol
<ifreund>
yeah, if you have a lot of commits that don't compile it becomes less awesome
<noam>
Yeah, but that's on you :P
<noam>
(or, well, me)
<noam>
ifreund: or if it's broken for other reasons :P
mokafolio has quit [Quit: Bye Bye!]
hiljusti has quit [Ping timeout: 245 seconds]
TheLemonMan has quit [Ping timeout: 246 seconds]
<earnestly>
(git isn't your editor's save function heh)
<noam>
*shouldn't* be your editor's save function lol
waleee-cl has quit [*.net *.split]
Raito_Bezarius has quit [*.net *.split]
catern has quit [*.net *.split]
skuzzymiglet has quit [*.net *.split]
detha has quit [*.net *.split]
waffle_ethics has quit [*.net *.split]
CommunistWolf has quit [*.net *.split]
notzmv has quit [Ping timeout: 240 seconds]
Raito_Bezarius has joined #zig
waleee-cl has joined #zig
catern has joined #zig
detha has joined #zig
skuzzymiglet has joined #zig
waffle_ethics has joined #zig
CommunistWolf has joined #zig
Raito_Bezarius has quit [Max SendQ exceeded]
catern has quit [Max SendQ exceeded]
CommunistWolf has quit [Max SendQ exceeded]
CommunistWolf has joined #zig
jokoon has quit [Quit: Leaving]
Raito_Bezarius has joined #zig
Snektron has quit [Ping timeout: 246 seconds]
AtomToast has quit [Ping timeout: 245 seconds]
ugla has quit [Ping timeout: 245 seconds]
fengb has quit [Ping timeout: 245 seconds]
siraben has quit [Ping timeout: 245 seconds]
patwid has quit [Ping timeout: 240 seconds]
patwid has joined #zig
mokafolio has joined #zig
<mikdusan>
do we have any desire for x86_64-macos to enable qemu during testing?
<mikdusan>
oh wait; no qemu-user mode on macos. for get I mentioned it :)
AtomToast has joined #zig
<noam>
andrewrk: if there's an @Foo(), for some nonexistent builtin Foo, and it doesn't get referenced, is the compiler supposed to notice? From the grammar + lazy analysis, I suspect no, but figured I should confirm
<g-w1>
yes, because everything gets astgened
<noam>
I'm asking about how it's *supposed* to work, not necessarily the current behavior :P
ugla has joined #zig
<g-w1>
i think that is how its supposed because the proposal was accepted
<noam>
I *think* you're correct, though...
<noam>
But it could easily go either way
<andrewrk>
a refined version of this question is: builtins are supposed to be part of the parser spec; an invalid builtin name is a parse error
<noam>
andrewrk: the grammar says a builtin identifier is just @ IDENTIFIER, though
fengb has joined #zig
Snektron has joined #zig
<noam>
(not exactly, but yeah)
<andrewrk>
sorry, I edited that sentence and it stopped making sense. clarified: builtins are supposed to be part of the parser spec; an invalid builtin name is supposed to be a parse error
<andrewrk>
I see that this is not currently implemented in zig-spec
<noam>
Gotcha, okay, thanks :)
<g-w1>
hmm, would that make the parser use less memory if implemented? because strings -> tags?
<noam>
Tweaking my handling of builtins 'cause I'm adding panic + tests :)
<noam>
g-w1: not by much, in theory
<andrewrk>
resources are not really a concern at this layer of design, it's more just about keeping the lang spec simple
<noam>
Sure, but it's also nice to know whether an impact exists
tomku has quit [Read error: Connection reset by peer]
<noam>
... hmm, maybe not.
<noam>
Even if it's not intentional, that can influence design in undesirable ways
<g-w1>
i see, but if that is the spec, it would make sense to implement it correctly. for example, if i wanted to use the parser in a seperate project, if the spec says @Foo shouldn't parse, but std.zig accepts it, that should be wrong
tomku has joined #zig
<noam>
I'm just going to use a hash table of acceptable values :P
<andrewrk>
g-w1, that's correct, when the spec disagrees with the implementation, it is either a bug in the implementation, or in the spec
<andrewrk>
bugs are to be expected when both are rapidly changing
<andrewrk>
this is why we're not 1.0 yet
<g-w1>
makes sense, i was just thinking that the if the spec said the parser should validate builtins, a nice optimisation would be to use tags for each builtin
<noam>
I really dislike 8643; I think daurminator's suggestion for expanding @Type makes more sense...
<noam>
andrewrk: what's the motivation for a dedicated builtin over expanding @Type?
ugla has quit [Ping timeout: 245 seconds]
<andrewrk>
why is everybody so obssessed with meta programming? stop it, lol
Snektron has quit [Ping timeout: 258 seconds]
<noam>
?
jokoon has joined #zig
<noam>
@Type already exists - why make a special case for this?
AtomToast has quit [Ping timeout: 276 seconds]
<andrewrk>
declarations are not allowed in @Type, plus it's a worse language than normal declarations
<noam>
True
<ifreund>
fuck, I totally forgot to rebase a PR for the std.testing changes and broke master. Will fix shortly
<mq32>
andrewrk: is that decided now? *grin*
<noam>
What's the advantage over 4245?
<noam>
That is, struct (.{ .layout = .Extern })
<ifreund>
let it be known that green CI may be a lie on PRs older than a few days
<mikdusan>
green is for sick
siraben has joined #zig
fengb has joined #zig
Snektron has joined #zig
ugla has joined #zig
AtomToast has joined #zig
ur5us has joined #zig
jokoon has quit [Quit: Leaving]
Akuli has quit [Ping timeout: 260 seconds]
Bernstein has quit [Remote host closed the connection]
<v0idify>
hmm, i remember i ended up choosing zig-opengl for some reason. is there a reason i shouldn't be using zgl?
<noam>
because OpenGL sucks? /s
<v0idify>
zig-opengl != zgl, i'm comparing zig libraries here :P
<v0idify>
or, well, zig-opengl are autogenerated bindings and zgl are homemade bindings :P
<noam>
I got that lol
<noam>
In that case, I'd say use zgl
<noam>
handwritten bindings are almost always better
<v0idify>
yeah, that's why after re-reviewing it i don't get why i didn't choose it (apart from it missing features but those can easily be implemented)
<v0idify>
i'm building a terrible, badly written gui library :D
<noam>
Good news: there are no good GUI libraries :P
<noam>
So you'll be in good company, at least!
<v0idify>
yay!
<noam>
I'd aim for "well-written" over "good" for a GUI library, personally
<v0idify>
dw it won't be well written either :D
<v0idify>
it will be zig fmt'd at least
<v0idify>
this is my strategy of having such bad expectations so when i release something no one will be disappointed
hiljusti has joined #zig
<noam>
I'll be disappointed *now* instead! :P
v0idify has quit [Remote host closed the connection]