<pixelherodev>
Have it accept {d} and {x} for arrays of numbers, and call format for each entry with the given options
<pixelherodev>
One line, in standard library, and gives better behavior :)
<leeward>
maybe after I figure this thing out
aerona has quit [Read error: Connection reset by peer]
aerona has joined #zig
<pixelherodev>
Ooh, andrew's function params merged :)
<pixelherodev>
andrewrk: nice work :)
stripedpajamas has joined #zig
aruniiird has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
B4s1l3 has joined #zig
B4s1l3 is now known as opDispatch
<marler8997>
andrewrk, where is the data on the ArenaAllocator perf regression?
<marler8997>
oh you left it in the comment, I'll take a look
stripedpajamas has quit [Quit: sleeping...]
aerona has quit [Quit: Leaving]
<marler8997>
andrewrk, I'm running the benchmark manually and it's consistencly running faster with the latest version of ArenaAllocator
<marler8997>
Using C allocator as the underyling allocator, compiling with --release-fast and -lc, new ArenaAllocator is consistently 33% faster
<pixelherodev>
marler8997: What about page_alloc?
<marler8997>
I'll try that, one moment though, I think I was testing the wrong branch
<marler8997>
ok with page allocator, I think I am getting a consistent slowdown, from .004s to .005s
<pixelherodev>
:(
<andrewrk>
marler8997, interesting, I wonder why we are seeing different results
<marler8997>
andrewrk, I think I'm seeing the same results now
<marler8997>
I was using the wrong branch
<marler8997>
I'm trying some experiments, my best guess is that storing the metadata at the end of the allocation could be messing up cache predictability
<andrewrk>
that sounds likely
<andrewrk>
I tried to make the benchmark mimic the access patterns of real world use cases
<marler8997>
Going to take my branch and keep all the changes but move the metadata back to the start of the buffer and see what I get
haliucinas has quit [Read error: Connection reset by peer]
haliucinas has joined #zig
<marler8997>
ok I'm getting the slow speeds even when I move the BufNode back to the start of the buffer
<marler8997>
I think the problem may be that the old version was allocating larger arenas than the new version
<marler8997>
new version says, give me at least as much memory as the client requested from me
<marler8997>
old version said, bug me at least 150% of what was requested from me
yeti has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
<marler8997>
old version is also adding the size of the previous buffer to the size of the next buffer, so it makes much larger allocations later on
<marler8997>
modifying mine to do that as well makes it faster, but I think the old version is still faster than mine with those changes
<marler8997>
I'll make PR to revert to the old version, but just keep the change in to use the full capacity of allocations
wootehfoot has quit [Ping timeout: 260 seconds]
marnix has joined #zig
marnix has quit [Client Quit]
Aransentin has left #zig [#zig]
<andrewrk>
marler8997, oh I didn't realize you reverted the superlinear growth
<andrewrk>
yeah the superlinear growth is intentional
_Vi has joined #zig
doublex has quit [Remote host closed the connection]
<owl_000>
in raspberry pi zero (arm6) simple hello.zig program takes too long to compile.
<pixelherodev>
Not surprised
<pixelherodev>
Stage1 isn't the fastest compiler around.
<owl_000>
oh
<owl_000>
i knew that, i just wanted to inform you about that
<alexnask>
How long does it take? Just curious
<owl_000>
too long, even rust compiles earlier than zig
alexnask_ has joined #zig
alexnask has quit [Ping timeout: 272 seconds]
<pixelherodev>
wow
<pixelherodev>
that's really bad...
<pixelherodev>
owl_000: thanks, good to know
<alexnask_>
yeah this is surprising every time Ive used rustc I wondered if it hang
<pixelherodev>
I'm going to be working on improving ARM support today, so I appreciate the info
<owl_000>
welcome,
<pixelherodev>
andrewrk: whenever you see this: any objections to making CPU feature detection part of stdlib instead of src-self-hosted
<pixelherodev>
I can definitely see uses for it in other applications (JITs for instance ;)
<pixelherodev>
It could also be used to switch between hand-optimized asm for CPU-intensive workloads
ur5us has quit [Ping timeout: 260 seconds]
matti has joined #zig
owl_000 has quit [Remote host closed the connection]
Mulugruntz has joined #zig
dermetfan has quit [Ping timeout: 260 seconds]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
aruniiird has joined #zig
dermetfan has joined #zig
alexnask_ is now known as alexnask
dermetfan has quit [Ping timeout: 260 seconds]
aruniiird has quit [Ping timeout: 260 seconds]
ofelas has quit [Ping timeout: 272 seconds]
gazler_ has joined #zig
dermetfan has joined #zig
gazler has quit [Read error: Connection reset by peer]
gazler__ has joined #zig
dermetfan has quit [Ping timeout: 246 seconds]
gazler_ has quit [Ping timeout: 246 seconds]
ofelas has joined #zig
aruniiird has joined #zig
Aransentin has joined #zig
<Aransentin>
Is there a way of checking whether a variable is used anywhere else in the code? If so, it'd be kinda useful for function-loading libraries (e.g. for OpenGL and Vulkan). If you know that the function "vkDoStuff" is never called you don't have to bother with loading it from the driver.
<pixelherodev>
You could hook that up to the build system
<Aransentin>
How so? I guess "scan the code for the string 'vkDoStuff' and set 'vkDoStuff_used' to true if found"...?
<pixelherodev>
Exactly
<pixelherodev>
That's definitely going to be your best bet
<pixelherodev>
I'd have it scan via the AST
<pixelherodev>
Use std.zig to parse the source code, make a list of all function calls, and then check by prefix
<ifreund>
it seems like there should be a better way than parsing the code
<pixelherodev>
I disagree
<pixelherodev>
Parsing the code gives you advantages that can't be obtained through any other method
<ifreund>
if what you want to achieve is optional dependencies just make a build option and disable branches at comptime
<pixelherodev>
For instance, you can check for usage as function calls and ignore usage in e.g. strings
<pixelherodev>
It also means lazy evaluation applies
<Aransentin>
Ah, lazy evalution is totally needed for my toy Vulkan example, for sure. Don't want to load "vkDoSomeWindowsThing" on Linux when it's just in a `if(windows)` block.
<pixelherodev>
That's exactly what I was thinking of :)
<alexnask>
This is basically what zls does to find references to rename. I build a basic symbol table for every file then traverse asts and resolve the type of expressions and get declarations from identifiers
hamoko[m] has joined #zig
<alexnask>
(though I dont do any comptime evaluation exceept for binding type parameters in type function calls)
<nerthus>
is it possible to do that for C imports in the future as well?
<nerthus>
alexnask
<alexnask>
I tried getting cImport support at some point, there are a couple of roadbloacks
<alexnask>
But it will be possible at some point
<alexnask>
Mostly the difficulty is getting the correct cache hash, it depends on a tonne of stuff and the std lib cache hash api is not compatible with the compilers C++ implementation
<pixelherodev>
Yet
<pixelherodev>
Rather
<pixelherodev>
Soon, it won't matter
<pixelherodev>
Once the self-hosted cache hash is done, right?
<alexnask>
The plan is to transition the libcs in the global cache to using it first
<alexnask>
From what Ive seen
<alexnask>
I think someone was working on that, I pointed them to relevant parts in discord, idk if they abandoned it
<alexnask>
Then I suppose we could also transition C source files to use the a self hosted cache hash but this would be a little more involved
<alexnask>
But even then I would have to extract a bunch of data from the build file and make some assumptions to calculate a hash
<alexnask>
But anyway yeah in theory its possible :P
gpanders has quit [Ping timeout: 265 seconds]
Aransentin has quit [Remote host closed the connection]
Aransentin has joined #zig
gpanders has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
pmwhite has quit [Quit: killed]
alva has quit [Quit: killed]
ifreund[m] has quit [Quit: killed]
Snektron has quit [Quit: killed]
zannzen[m] has quit [Quit: killed]
return0e[m] has quit [Quit: killed]
fengb has quit [Quit: killed]
hamoko[m] has quit [Quit: killed]
BaroqueLarouche has quit [Quit: killed]
layneson has quit [Ping timeout: 241 seconds]
gpanders has quit [Ping timeout: 265 seconds]
jicksaw has quit [Ping timeout: 246 seconds]
jicksaw has joined #zig
gpanders has joined #zig
gpanders has quit [Ping timeout: 256 seconds]
ifreund[m] has joined #zig
gpanders has joined #zig
alva has joined #zig
fengb has joined #zig
pmwhite has joined #zig
return0e[m] has joined #zig
hamoko[m] has joined #zig
BaroqueLarouche has joined #zig
Snektron has joined #zig
dddddd has joined #zig
dermetfan has joined #zig
waleee-cl has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
penguinicus has quit [Remote host closed the connection]
penguinicus has joined #zig
penguinicus has quit [Remote host closed the connection]
drewr has quit [Remote host closed the connection]
drewr has joined #zig
Aransentin has quit [Remote host closed the connection]
penguinicus has joined #zig
Akuli has joined #zig
Aransentin has joined #zig
<Aransentin>
A slightly annoying thing with how errors work:
<Aransentin>
A lot of code uses functions that return errors to check whether some piece of data is valid, e.g. `getAddressList()` first checks if the string you passed to it is an IP address, and only does an acutual DNS request if the IP parsing fails. Fine.
<Aransentin>
The problem is that the failed "is this an IP address"-check adds an entry to the traceback, so when something _actually_ breaks much later in the program you're going to have a million "benign" errors to wade through before the actual relevant error shows up.
<Aransentin>
Can this be fixed in some way, or do we just live with it?
layneson has joined #zig
<leeward>
I'm not sure what you mean by fix. It sounds like "this is not an IP address" is valuable information, and so is "getAddressList call failed."
<Aransentin>
Ah, no, getAddressList worked fine
<leeward>
That sounds like your problem there. Fail early.
<alexnask>
Aransentin, you are talking about the error trace right?
<Aransentin>
Yeah
<alexnask>
Yeah I feel you, I also handle FileNotFound and get error traces for it anyway sometimes
<Aransentin>
Hmmm, let me explain a bit better
<Aransentin>
If you do a DNS lookup of a non-IP string at the start of your program, every return trace after that will start with an error from `std.net.Address.parseIp4` because that's what led you to the point in the program you are currently.
shcv has joined #zig
<Aransentin>
Call a few other functions that do the same thing and the error trace will get filled to the brim with confusing lines you don't care about.
<leeward>
Oh, because the error was handled but still shows up in the trace?
<blinghound>
would std.time.Timer be the most appropriate clock source for calculating delta time between frames?
<mq32>
blinghound: yeah, i think so
<marler8997>
andrewrk, adding superlinear growth to the new version made it faster, but I'm not sure it was as fast as the original. The old version also added more length to the initial allocations, alignment, plus added 150% of what was requested
<shcv>
is there a way to declare types for literal values?
<shcv>
I want to do 1<<i, but it says that the LHS has to be typed or the RHS known at compile time...
<blinghound>
mq32 seems to work well now, there were more nanoseconds in a millisecond than I thought
<fengb>
`@as(u32, 1) << i`
<shcv>
thx
<blinghound>
marler8997 is this for an allocator?
<marler8997>
Yes, ArenaAllocator
<blinghound>
could growth rate be a user provided comptime parameter?
<mq32>
blinghound: there are a lot of nanoseconds
<fengb>
Seems weird that it just adds more to the original request
<fengb>
"Hey you said 4K but I know you mean 6K"
Aransentin has quit [Remote host closed the connection]
<blinghound>
mq32 lol yup, my initial u32 was starting to sweat
<marler8997>
yeah...lol
Aransentin has joined #zig
<marler8997>
I don't think it's a big deal either way, it's a standard allocator, meant to serve the general case. If an app wants something more specific they can always roll their own allocator
<blinghound>
yeah true, it's easy enough to allocate a big chunk using any allocator and use your own growth factor rules
<blinghound>
by the way, I haven't looked at the source code, but I assume that c_allocator just wraps malloc right?
opDispatch has quit [Remote host closed the connection]
opDispatch has joined #zig
<scientes>
Akuli, overflow is always a special case, and you have to be explicit you expect it in zig
<Akuli>
yes, and this is one of the cases where overflowing subtraction is useful
<scientes>
i think you should just rewrite it to avoid the overflow
<scientes>
the overflow is always more confusing
<scientes>
(not that I always do that)
<Akuli>
if you use unsigned integers for tracking time, then how do you check if some amount of time has passed?
<marler8997>
time checking is a case for using overflow
<Akuli>
just use a huge type that won't overflow in a sane amount of time?
<scientes>
Akuli, how often do you deal with actual time?
<scientes>
time almost always comes from the OS in some way
<scientes>
and you need to set a wake-up timer etc
<Akuli>
most recently i used SDL_GetTicks() which returns 32-bit unsigned
<scientes>
even in OSes like seL4
<Akuli>
in milliseconds
<Akuli>
hmm actually, i'm limiting a loop to run FPS times per second, and i increment a counter in that loop
<Akuli>
a 32-bit unsigned counter
<marler8997>
timeDiff = newTime -% oldTime
<shakesoda>
getticks for frame limiting, or any accurate time measurement at all, is so awful D:
<marler8997>
that should handle overflow as well
<scientes>
you need to call into the OS to avoid a busy loop
<Akuli>
shakesoda, afaik you can't vsync in sdl2?
<shakesoda>
um, yes you can
<Akuli>
hm
<shakesoda>
but also ticks is the worst time measurement it offers
<Akuli>
works for me lol
<Akuli>
anyway
<Akuli>
i remember someone complaining about not being able to vsync in pygame, which is essentially sdl2 for python
<shakesoda>
you can set the swap interval to make the OS vsync, but millisecond precision isn't anywhere near enough to maintain consistent timing
<Akuli>
so i thought it was an sdl2 issue
<shakesoda>
you almost always want the perf counter
<Akuli>
for FPS=60, the loop runs 16.666... ticks per second
<Akuli>
given that, off by less than a tick doesn't seem too bad to me?
<scientes>
you mean ticks per frame
<Akuli>
umm yes, ticks per frame
<shakesoda>
that means you're missing the frame timing... basically always, and accumulating a fair bit of error if you've got anything which should stay even close to real time
<scientes>
and you can't really assume linux is 1000mhz
<scientes>
it has 240 and 250 and 100mhz settings
<shakesoda>
you usually want SDL_GetPerformanceCounter() to do better than this, divide by SDL_GetPerformanceFrequency() to turn it into seconds
<Akuli>
shakesoda, frame timing might not be very close to real timing anyway, with a shitty computer and some other program doing something randomly it may drop quite a lot sometimes
<shakesoda>
you'll basically never ever be able to get even slightly consistent timing at only millisecond resolution.
<Akuli>
so i just calculate all other stuff from frame time
<Akuli>
how consistent is "even slightly consistent" to you?
<Akuli>
and when would non-"even slightly consistent" timing matter?
<shakesoda>
if you're driving animations with this, it matters a hell of a lot, because you can easily miss vsyncs if your timing isn't precise enough, or if you are driving a fixed time step on this you'll be missing *frequently*
<shakesoda>
timing will also drift very quickly and screw up basically everything
<Akuli>
hm
<Akuli>
maybe it's just me not being a gamer
<Akuli>
i can barely tell the difference between 30fps and 60fps
<shakesoda>
and if you're waiting on something that imprecise you'll miss your vsyncs every time
<Akuli>
i'm quite sure i'm getting it right most of the time
<shakesoda>
also, god help you if someone isn't using a 60hz display
<shakesoda>
but syncing on a 60hz timer screws them to begin with
<shakesoda>
non-60hz displays aren't even that uncommon
<scientes>
extremely common
<scientes>
NTSC and PAL is still a ting
<shakesoda>
59.94 is extremely common, 120+ is common now (high refresh rate/variable sync gaming monitors), 72 and 90 are common in VR...
<shakesoda>
pal exists
<shakesoda>
anyway, inaccurate time deltas ruin your timing and you also end up with not having enough precision for animation to be smooth at only millisecond accuracy
<shakesoda>
it'll have weird jitter, because your input data is no good
<fengb>
You can tell 30-60 once you get used to it. Pretty noticeable
<Akuli>
i was about to ask what unsmooth animation and ruined timing look like
<fengb>
Even going up to 144 you’ll be able to tell
<Akuli>
because i have never noticed either of those with my millisecond precision code
<shakesoda>
unsmooth = jitters, a smooth scroll won't be perfectly smooth. ruined timing = 1 second not being 1 real second - you won't be able to sync timers up with *any* degree of certainty
<Akuli>
and why exactly is ruined timing an issue?
<Akuli>
depends a lot on what you do i guess
<Akuli>
i imagine it would matter for any kind of thing that has to be in sync with many people interacting with it from different computers
<leeward>
or running different levels of simulation at different time steps
<Akuli>
so yeah
<shakesoda>
all of these issues get magnified if you have any kind of time accumulation
<Akuli>
this is the kind of garbage you get when a non-gamer tries to build a game :D
<shakesoda>
because the error increases very, very quickly
<shakesoda>
handling for variable refresh rates is where this really gets nasty, especially as the rates get higher
<Aransentin>
You pretty much need to have your windowing system tell you "Hey, I've flipped your image so please give me a new one" and react to that.
<Akuli>
as in requestAnimationFrame in javascript world?
<shakesoda>
that's one mechanism for this, yeah
<shakesoda>
inaccurate time deltas will cause you problems whenever you do integration really
<shakesoda>
any position += speed * delta will turn into a mess if your delta is inconsistent or imprecise
<fengb>
gameprogrammingpatterns.com
<fengb>
Game loop describes this in detail
<shakesoda>
sounds better than me dumping this in the channel :)
<Akuli>
hmm
<Akuli>
the recommended way in pygame is pygame.time.Clock().tick
<shakesoda>
gaffer on games has some good articles about these things too
<Akuli>
and that uses SDL_Delay and SDL_GetTicks() :D
<shakesoda>
i'm getting the impression that perhaps pygame needs... work
<shakesoda>
it's really easy to not take timing seriously, but timing issues can be really sinister
<shakesoda>
if i seem very insistent about this, it is from being burned very badly (incl. on commercial projects, where people ought to have known better up front, and made messes which essentially could not be fixed)
<shakesoda>
bad time accumulation can manifest even in simple games by things like sometimes an animation just not stepping when expected, or stepping twice when unexpected, or mysteriously missing a target
layneson has joined #zig
<Akuli>
yeah i have had players running through walls in this project :D
<Akuli>
i thought about implementing something like semi-fixed timestep, but just setting fps high enough "fixed" it
aruniiird has quit [Ping timeout: 256 seconds]
<shakesoda>
in practice i do a fixed timestep for everything and interpolate moving objects between current/next state for display, so slight desync with the updates and the display don't result in jitter
<shakesoda>
the solution i use is almost exactly the same as the one in the article i just linked, near the bottom
<Akuli>
their last example code?
<shakesoda>
yeah.
<shakesoda>
the details are the slightest bit different, but it's functionally equivalent to what i do everywhere.
<Akuli>
maybe i should tell a bit more about this project
ofelas has quit [Ping timeout: 260 seconds]
<Akuli>
it's my attempt at making something playable with not much game-specific knowledge, and learning a lot along the way
<Akuli>
turns out that i ended up rediscovering a lot of 90's game programming techniques, lol
<shakesoda>
as one does
<Akuli>
i read the thing you posted
<Akuli>
the last code example is ... better than i expected :D
<tdeo>
wl_shm doesn't need c libraries, and linux-dmabuf doesn't *technically* but in practice does need something to generate the dmabufs which i believe are platform specific
<Aransentin>
Yeah, there's the vulkan extension to do it
<tdeo>
but one goal is to use a pure zig x11/wayland library while also linking to the C libraries for opengl/vulkan, which is possible with x11 DRI3 or wayland linux-dmabuf
<Aransentin>
That's exactly the plan :)
<tdeo>
but linux-dmabuf won't work on nvidia, if you care about that
<tdeo>
(not that you should :p)
<Aransentin>
haha
<tdeo>
nor will dri3
<Aransentin>
Now that's a little concerning. I have to figure out if there's a way of sharing GPU memory between X11 and nvidia+Vulkan, then... Hacing "EGLstreams" into it I suppose, however that works.
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<shakesoda>
yeah nvidia is really problematic here
<shakesoda>
it's very frustrating
<Aransentin>
Hm, from a cursory googling it seems possible, as you can just get an opaque fd from Vulkan that represents the nvidia memory which you then feed into X11.
<Aransentin>
It won't be a *dmabuf* under the hood, but it'll work mostly the same.
<shcv>
how do I get a []u8 when I have a []const u8? I presume it's const because I used a literal?
<shcv>
though I don't actually need it to be mutable; maybe it would be better to copy the PacketIntArray code and make an immutable version without setBits, etc.
<shcv>
assuming that would avoid the complaint about expecting a []u8...
<shakesoda>
shcv: you have to copy it to get a mutable reference to it
<shakesoda>
shcv: the literals are always going to be const
<shakesoda>
in general turning things const is one-way, and the only way back is a copy (that's the point!)
<shcv>
what's the right way to initialize a slice then?
mmx870 has quit [Quit: Ping timeout (120 seconds)]
<Akuli>
shakesoda, i think you linked the thing that weighted-averages out the previous and current state so that it goes between the game time steps nicely, how do you structure your data? if you have lots of moving enemies, for example, do you have a struct Enemy and just make copies of all Enemies even though you really only need new averaged locations for them?
<Akuli>
i guess the code that shows the stuff could take the location as an argument instead of looking it up from the struct, but that feels a bit ugly
<JimRM>
Hey. Anyone know how I can disable Neon when compiling arm64?
<shakesoda>
Akuli: my entities have a flag set on them if they're active and they keep a copy of their previous locations.
<Akuli>
where do you calculate the mixed location?
<Akuli>
right before it's needed in the drawing code?
<shakesoda>
i do a pass over the entities to figure out the drawables before render and do it there
<Akuli>
so, your rendering functions look like render(entity, alpha)
<Akuli>
rendering needs to know alpha, the number describing how to mix new and old positions?
<shakesoda>
no, i mix beforehand, but it's equivalent anyways
<Akuli>
so rendering function uses your entity structs and a mixed location that comes as a separate argument?
<Akuli>
that seems about as clean as it can be
<shakesoda>
i don't render one at a time, i gather all entities into an array and render that.
<Akuli>
yeah you're not stuck to the 90s like i am :D
<shakesoda>
that gathering is a good opportunity to also do the mixing since i'm already there, so that's where it happens
<shakesoda>
doing things one at a time is really bad for performance, heh
<Akuli>
yeah i have some vectorized code too
<JimRM>
Or a way for me to pass "-fp-armv8" to llvm?
<shakesoda>
JimRM: are there actually any armv8 devices without neon fpus?
<shakesoda>
i thought it was required
<shakesoda>
if there are specific cores that don't have that, you can probably specify the cpu type to get the right flags set for you
<JimRM>
Yes, but I don't want neon enabled in my binary :)
<shakesoda>
odd, but okay
<JimRM>
(it's a bare metal thing, and I do not enable FPU instructions - so any NEON instructions cause an illegal instruction fault)
<shakesoda>
oh, that makes sense, although i should think you usually would just enable the fpu... i will trust you have your reasons
<shakesoda>
i don't know the incantation for it, but i'm quite sure you can do what you're after here
doublex__ has joined #zig
<JimRM>
All I am looking for is a way to pass that compiler flag to LLVM - I cannot find anywhere in the docs which show me how to do that. I assume passing custom flags is a fairly common thing to do?
doublex_ has quit [Ping timeout: 260 seconds]
<andrewrk>
JimRM, you can can set cpu feature flags in the target
<andrewrk>
JimRM, use `zig build-exe foo.zig -target arm-freestanding-none -mcpu=help` to see the list of cpus available
<andrewrk>
and use `zig build-exe foo.zig -target arm-freestanding-none -mcpu=generic+help` to see the list of cpu features available
<andrewrk>
you can see that fp_armv8 is in the list
<JimRM>
andrewrk: Thanks!
<andrewrk>
so you want -mcpu=yourcpuchoice-fp_armv8
<tgschultz>
neat, thanks to .modifier = .always_tail, it looks like jump tables and continuations are totally doable now.
<andrewrk>
JimRM, if you choose generic be sure to add in the cpu sub-architecture feature, e.g. generic+v8a
stripedpajamas has joined #zig
Mulugruntz has quit [Quit: ZZZzzz…]
ur5us has joined #zig
ofelas has quit [Ping timeout: 240 seconds]
ofelas has joined #zig
cole-h has quit [Quit: Goodbye]
kllr_sbstn has joined #zig
Akuli has quit [Quit: Leaving]
wilsonk has quit [Ping timeout: 260 seconds]
kllr_sbstn has quit [Quit: leaving]
waleee-cl has joined #zig
<shcv>
how can I switch on a tagged enum I'm getting from a next() method, in such a way that I can replace the value?
<shcv>
I'm trying to write an insert function
<shcv>
it would be nice if I could do something like switch(table.next(key)) { .Empty => |e| { ...insert stuff... }}
<shcv>
but I'm not sure how to do that, since e is just void
<ifreund>
er, would probably be const thing since it's a pointer I assume
wilsonk has joined #zig
<shcv>
does the switch change any when dealing with a pointer?
<ifreund>
well, you'd probably do switch(thing.*)
marnix has quit [Ping timeout: 258 seconds]
Aransentin has left #zig [#zig]
wootehfoot has quit [Read error: Connection reset by peer]
ofelas has quit [Ping timeout: 240 seconds]
nikita` has quit [Quit: leaving]
<shcv>
how can I trace where the constness is coming from?
ofelas has joined #zig
_Vi has quit [Ping timeout: 260 seconds]
<shcv>
trying to update a field of a struct in a method, "table.map |= ...", and it says "can't assign to constant"; so I assumed I needed "self: *Table" instead of "self: Table", but now it's complaining about receiving *const Table
<shcv>
are the |value| results from a switch statement always const?
<alexnask>
yes you can do |*value| to get a pointer
<alexnask>
to the payload
dermetfan has quit [Ping timeout: 246 seconds]
<pixelherodev>
andrewrk: ah sick, didn't know that
<pixelherodev>
Teaches me to ask before looking :)