<Snektron>
Is cache_hash.zig ready for usage in build.zig? i'm trying to write some code generation stuff
ur5us has quit [Ping timeout: 256 seconds]
swills has joined #zig
<andrewrk>
probably not quite yet
<Snektron>
Right. Do you have a recommendation for an alternative approach?
aerona has joined #zig
<leeward>
Oh cool, llvm isn't filling in the interrupt vectors when it generates this code. That explains a bit.
blinghound has quit [Remote host closed the connection]
craigo has quit [Ping timeout: 264 seconds]
<andrewrk>
lemmi, in your hash map example code for Euler 14, is the ensureCapacity intended to be a true upper bound? or is it just a heuristic?
<andrewrk>
I'm observing 22022059 puts even though the ensureCapacity sets it to 2000000
<leeward>
Right, of course. The linker does that, and llvm uses gcc's linker for avr.
<leeward>
\o/ executing Zig code on an AVR, it's not crashing, and functions are working.
<leeward>
It's an awful pile of hacks on top of kludges, but it works.
<leeward>
And it works in debug mode!
<leeward>
Next step: simplify this linker command.
<leeward>
andrewrk: It looks like some of the experimental llvm targets use GCC's ld to link. Does Zig have any way to deal with this? If not, I think we'll have to emit .o files and link them in a separate step. I'm certainly not in a hurry to add ld as an actual Zig dependency, but maybe it could use it if it's available?
<andrewrk>
it's not planned for zig to ever be a driver of external system tools
<andrewrk>
we'll gain support for linking avr within the zig project itself
<andrewrk>
our goal is not to catch up to gcc; it's to surpass it :)
<leeward>
Ok, so for all the llvm targets that use gcc as a linker the plan is to implement (or add a configuration for) a linker in Zig?
<leeward>
I'm guessing that's ultimately true for all the targets llvm has, regardless of how it handles them.
<andrewrk>
yes, or ditch the llvm backend altogether in favor of the pure self hosted one
<leeward>
Ok, cool. Ambitious, but cool.
<leeward>
found a 3A USB power supply, so it's time to try building Zig on an RPi 1B again.
aerona has quit [Quit: Leaving]
stripedpajamas has joined #zig
aerona has joined #zig
forgot-password has quit [Ping timeout: 240 seconds]
<yeti>
leeward: do you have some public notes about zig+AVR in the net?
<leeward>
yeti: not yeti
<yeti>
sleep on it... ;-)
forgot-password has joined #zig
<yeti>
is there a way to ask zig/llvm on a system to detect the nedded cpu settings?
<leeward>
needed cpu settings for what?
<leeward>
like, for targeting your build host?
<yeti>
I stlll have crashes on Pi2 and Cubietruck
<leeward>
'cause that's native-native-native
<leeward>
or just no -target
waleee-cl has quit [Quit: Connection closed for inactivity]
<yeti>
te downloaded armhf zig crashes compiling some c files
<yeti>
the self build one needes some extra flags not to use wrong instructions
<yeti>
zig-bootstapp -j# native-native-native native would work?
<yeti>
I've bootstraps running with arm-linux-musleabihf baseline (and nativ) on 2 Pi2 and 2 Cubietrucks but am not really sure that it is the right triple
<yeti>
raspian on pi2, devuan on cubie3
forgot-password has quit [Ping timeout: 246 seconds]
fraktor has quit [Ping timeout: 256 seconds]
<andrewrk>
I need some more hash map benchmarks to figure out if #5786 is an improvement or not
<yeti>
Lets hope for no blackouts by thunderstor,... I'm prpard to maybe need to wait a week
<lemmi>
andrewrk: i was running straces and just put in a number such that only one allocation was necessary.
stripedpajamas has quit [Quit: sleeping...]
<lemmi>
andrewrk: my thought was to not benchmark the allocator, so i just tried a couple of numbers and 2M were good enough.
Techcable has quit [Remote host closed the connection]
Techcable has joined #zig
josias has joined #zig
dermetfan has joined #zig
josias has quit [Remote host closed the connection]
_whitelogger has joined #zig
discipulus has joined #zig
ifreund has quit [Ping timeout: 240 seconds]
ifreund has joined #zig
craigo has joined #zig
marnix has joined #zig
dermetfan has quit [Ping timeout: 244 seconds]
dddddd has joined #zig
VojtechStep has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
forgot-password has joined #zig
discipulus has left #zig [#zig]
dermetfan has joined #zig
_whitelogger has joined #zig
marnix has quit [Ping timeout: 256 seconds]
KoljaKube has joined #zig
layneson has joined #zig
Mulugruntz has quit [Read error: Connection reset by peer]
layneson has quit [Ping timeout: 264 seconds]
layneson has joined #zig
Mulugruntz has joined #zig
<lemmi>
soo.. i believe my swiss table is taking shape. i can insert and get. no deleteion or automatic grow/shrink, but still.
<ifreund>
lemmi: nice! you're ahead of my implementation then, I got distracted with other projects :D
<lemmi>
and i think i managed to do this with compelete parametric vecotr sizes
<lemmi>
so should we get hardare that can do 2k wide simd, this should still work :>
<ifreund>
well, doesn't that mean that you have a minimum allocation of 2k slots + the ctrl bits?
<ifreund>
i guess for some massive servers that could be a sane thing to do
<lemmi>
i wasn't saying it made any sense
<ifreund>
:D
<lemmi>
no, but should also work the other way around. there might be a groupsize that's beneficial to architectures even without simd support
<lemmi>
just because fiddling around the metadata and not comparing values might save some time
<ifreund>
yeah, parameterizing it is definitely the way to go
<ifreund>
google's impl kinda did this, they use 8 for non SSE capable hardware and 16 for SSE2 stuff
waleee-cl has joined #zig
<lemmi>
awesome. i actuelly can fill it up to capacity and replace existing keys. it correctly fails if i want to insert an anknown key in a full table
<lemmi>
even on a full table the amount of actual key compaisons is ridiculously small.
<ifreund>
yeah it's kinda amazing
<ifreund>
I'm finishing up my gtk patch then I need to get back to work on mine
<ifreund>
I only got as far as implementing the group sse stuff, didn't start the table yet
<lemmi>
ok, the rust implementation allows the table to fill to 7/8 before doubling the capacity
stripedpajamas has joined #zig
forgot-password has quit [Quit: leaving]
stripedpajamas has quit [Quit: sleeping...]
Nypsie has joined #zig
dddddd has quit [Ping timeout: 264 seconds]
<KoljaKube>
When interacting with C APIs, is there some nice way of translating to sentinel-terminated slices without having them leak all over my wrappers that I'm missing?
SimonNa has quit [Remote host closed the connection]
<lemmi>
tomorrow i'll try to get deletion going and i'll try to match the hashmap api
layneson has joined #zig
Nypsie has quit [Remote host closed the connection]
KoljaKube has quit [Ping timeout: 256 seconds]
layneson has quit [Ping timeout: 256 seconds]
Akuli has joined #zig
cole-h has joined #zig
layneson has joined #zig
layneson has quit [Ping timeout: 246 seconds]
dermetfan has quit [Ping timeout: 244 seconds]
dermetfan has joined #zig
<pixelherodev>
andrewrk: so should the CBE use an alternate Function impl?
<pixelherodev>
e.g. replace the entire backend with an API-compatible interface, the same way we have Scope.File and Scope.ZIRModule ?
<pixelherodev>
That seems the best way to preserve current behavior by default and make the C backend independent of architecture options but still able to handle architecture properly
aerona has joined #zig
layneson has joined #zig
<shakesoda>
has anyone managed to make a build.zig that spits out android apks
<shakesoda>
i figure it'd just be a matter of setting the right post build things, but i most certainly do not know what they would be
<leeward>
well, arm-linux-android is a target.
<leeward>
I have no idea what goes into an apk though.
dermetfan has quit [Ping timeout: 260 seconds]
<marler8997>
I've been spending too much time maintaining my own version of the windows APIs, going back and forth between developing my apps and maintaining the windows declarations
<leeward>
That sounds awful.
<pixelherodev>
That sounds like MS
<marler8997>
I'd be willing to go through the standard library and start filling it out
<leeward>
pixelherodev: That's what I said!
<marler8997>
if that's what zig wants
<pixelherodev>
;)
<pixelherodev>
marler8997: wait, we don't have windows support already?
<pixelherodev>
You mean low level std.os stuff is missing? or std.os.system?
<tgschultz>
we have some of the API in std
<marler8997>
std.ow.windows
<marler8997>
*std.os.windows
<marler8997>
I'd say about 70% of the time the function or declaration I need is not there
<tgschultz>
there is a *lot* of API in windows
<marler8997>
So I'm just constantly fixing up my own version, it's getting old having to go back and forth between my app and windows declarations
<leeward>
That's probably valuable work for the standard library, if you're willing to put it in.
<tgschultz>
when I was maintaining my own windows lib it was ~3Mb of source
<marler8997>
I'm willing to put in work to start working on the standard library, but it will be alot of work and I want to make sure this is the direction zig wants before I start
<marler8997>
I'm not even sure if Zig wants all the windows declarations in the standard library
<leeward>
Well, get andrewrk to weigh in. He's the most authoritative.
<marler8997>
yeah I'll wait for his thoughts
<marler8997>
while I'm at it, one thing I would love is a good description of the standard library organization
<marler8997>
would take alot of guesswork and investigation work away
<leeward>
You mean like what each of the things at the top level is for?
<ifreund>
the _ = c.foo() is needed because these ncurses functions all return things and zig won't let you silently throw away the returned values
<leeward>
Those return values should probably get used once you have anything working.
<ifreund>
probably yeah :D
<pixelherodev>
ifreund: that's what I was saying though
<pixelherodev>
e.g. std.os.write -> std.os.$SYSTEM.write , with e.g. std.fs.File -> std.os.write
<ifreund>
pixelherodev: perhaps I misunderstood though
* pixelherodev
shrugs
<pixelherodev>
Or I wasn't clear
<ai19>
oh, excellent, thanks a bunch, @ifreund and @leeward :-)
<ifreund>
I kinda doubt that std.os.write can map directly to a systemcall for every OS in the universe though
<leeward>
\o/
<ifreund>
ai19: no problem, good luck with your zig journey!
<ai19>
I guess I was thinking too simple.
<pixelherodev>
`Anyone who says that they're great at communicating but 'people are bad at listening' is confused about how communication works.` :P
<ifreund>
you can also build that zig main snippet I sent with zig build-exe -lc -lncurses main.zig
<scientes>
ifreund, even when you don't have an OS it is pretty close
<ifreund>
perhaps write was a bad example to use there :P
<leeward>
For write, sure, but what about creation?
<pixelherodev>
leeward: linkLibC is basically just a `if (!linked_libc) {linkSystemLibrary("c") linked_libc = true}` IIRC, except faster
<pixelherodev>
Slightly
<pixelherodev>
It goes through a lower-level API, which means avoiding e.g. checking pkg-config for libc
<leeward>
File creation varies pretty widely across operating systems. I don't know if there's a single sane interface that would unify them.
<pixelherodev>
If that were true std.fs.File wouldn't be possible ;)
<leeward>
Not true, because that's a special case.
<ifreund>
I don't think std.fs gives you all the control the syscalls do
<leeward>
Right, what ifreund said.
<leeward>
If it needs to, it can compose syscalls or only use a few options in one.
<ai19>
ifreund: thanks :) It's been like 15 years ago that I goofed around a bit with ncurses in C. Used it in Python CLI apps quite extensively though. 3 years ago, I became a great Go fan, but then Youtube suggested to me a talk by Andrew Kelly about Zig, so that got me curious. So I'm trying to see whether it's easier using ncurses through cgo, or trying to learn Zig and use it from there.
<shakesoda>
does dir api let me get fds, i want to do memory mapped file io
<shakesoda>
i can do it with c stuff if i need to of course
<ai19>
But of course, I really like the idea of Zig trying to be a better C :)
<shakesoda>
using c apis via zig can get you in a lot of awkward situations just from zig actually caring
<shakesoda>
or awkward situations because of macros that didn't translate
<shakesoda>
or at least didn't translate correctly
<ai19>
yeah, C macros could be a pitfall
<shakesoda>
it's one i run into a lot, the workarounds aren't difficult but it can be tedious.
<ifreund>
depends on the C really, and what the macros are doing
<ifreund>
some apis translate quite nicely
<shakesoda>
the failure rate for macros, especially ones with parameters, is... really high
<shakesoda>
in my experience, that is
<pixelherodev>
shakesoda: I've done MMIO
<pixelherodev>
I used std.os.open IIRC
<shakesoda>
for normal code, though, the translation is usually fine
<leeward>
For what it's worth, SDL is very usable without any hacking.
<shakesoda>
i think the only c interop problem i've had in recent memory was from passing structs by value
<pixelherodev>
I did std.os.openZ to get the handle
<shakesoda>
leeward: sdl is exactly a case where some of the macros in basic things fail to translate
<shakesoda>
lua, too :(
<yeti>
leeward: your zig bink test runs if assembled with naken_asm too
<yeti>
just the directives naken doesnt understand got filtered via a small awk oneliner
<leeward>
shakesoda: I've built small programs that work unmodified though.
<shakesoda>
i remember running into a few small issues *immediately* when using it, like i think SDL_INIT_EVERYTHING doesn't translate
<shakesoda>
not a big deal since that's just a convenience, of course
<shakesoda>
lua has more annoying problems
<shakesoda>
so my lua.zig has to reimplement several macros, heh
* yeti
needs to celebrate that with a tea...
dddddd has joined #zig
<pixelherodev>
shakesoda: lua.zig?!
<pixelherodev>
Does it work with luajit?
<pixelherodev>
No, the internals are different
<pixelherodev>
I wonder how much work it'd be to get LuaJIT working
<shakesoda>
pixelherodev: it works fine with luajit
<leeward>
yeti: I'd like to get the timer version working, but...really don't want to play the crazy linker games that might be required to put an ISR in place.
<shakesoda>
the thing you can't do with luajit is connect it to zig allocators
<shakesoda>
otherwise things are fine.
<shakesoda>
i didn't eve have to do weird stuff, just some macro workarounds.
<shakesoda>
*even
<pixelherodev>
Huh
<pixelherodev>
neat
<pixelherodev>
Couldn't you connect it to an allocator if you exported an interface though?
<shakesoda>
not luajit.
<shakesoda>
it rejects it
<pixelherodev>
e.g. `export fn jitalloc` `export fn jitfree` ?
<pixelherodev>
Why not?
<shakesoda>
it specifically enforces not using a custom allocator on 64 bit
<pixelherodev>
@cDefine(BLAH_ALLOC "jitalloc")?
<pixelherodev>
Ohh
<pixelherodev>
Okay
<pixelherodev>
So you can't do it in C either?
<shakesoda>
correct, not a zig issue
<shakesoda>
you'd have to hack the check out of luajit and make sure your allocator meets its needs.
<shakesoda>
not sure how this interacts with gc64
<pixelherodev>
Uh
<pixelherodev>
I don't think that's true
<pixelherodev>
There's a define for it
<pixelherodev>
LUAJIT_USE_SYSMALLOC
<pixelherodev>
If that's unset it allows custom allocators IIRC
<pixelherodev>
That's the condition for not exporting some APIs
<shakesoda>
hmmmm, well, i just let it be
<pixelherodev>
Hmm
<yeti>
leeward: I'm just starting to fail with zig... from blink to ISR still is a bit too far for me
<shakesoda>
luajit using its own allocator doesn't actually hurt me, it just slightly annoys me for the inconsistency in bookkeeping
<pixelherodev>
It might be that that switches between *bundled* allocator actually
<pixelherodev>
`* Undocumented, but hey, that's what we all love so much about Windows. */`
<pixelherodev>
lol
<yeti>
leeward: and on Pi2, Cubietruck and on Zsun no luck so far (armhf and mips)
<yeti>
but ommmmmmm...
<leeward>
Well, the pi should be easier. It's actually a supported architecture for llvm.
<yeti>
it complains about missing armv6k instructions because of yield... on bootstrapping
<yeti>
:-(
<yeti>
armhf should be arm7
<yeti>
well... raspians arkhf on pi1 might be different
<yeti>
to run on that arm6+hf chip
<shakesoda>
raspbian is armv6jzf-s or something.
<yeti>
but cubie3's A20 is "normal" armhf
<shakesoda>
i.e. armv6 + vfp2
<shakesoda>
i always forget the terms the compiler wants for that
<shakesoda>
arm1176jzf-s is probably what i'm thinking
<yeti>
armv7l <<< both... pi2 and cubie2/3
<yeti>
pi1 is that v6 thing
<shakesoda>
also pi zero
<yeti>
yes
<scientes>
armv7 really is much nicer
<shakesoda>
i have a handful of pi 0s
<shakesoda>
and some 3s and a 4 now. life is so simple on the 4...
layneson has joined #zig
wootehfoot has joined #zig
<pixelherodev>
Is the pi 4 more or less efficient than three?
<leeward>
It doesn't require a binary blob to get running.
<pixelherodev>
Whoa
<leeward>
They should have called them 3.1, 3.141592, 3, and 3.14.
<ifreund>
heh
<leeward>
I don't actually know when the first 0 is in pi...huh
<shakesoda>
pixelherodev: considerably more efficient
<leeward>
Wow, it's the 33rd digit.
* shakesoda
wants to see more usage of the uefi implementations available for the pi 3 and 4
<pixelherodev>
3.141592653589 is all I remember
<pixelherodev>
So, no zeroes
* pixelherodev
wants to see UEFI burned to the ground and everyone involved executed
<pixelherodev>
UEFI is a fustercluck and I hate it
<shakesoda>
pixelherodev: i'm not interested in the details of it, i just want to see standardized booting and acpi stuff on arm, so every damned machine doesn't need its own extremely specific os image
<pixelherodev>
Sure, I agree with the goal there
<shakesoda>
it's one of the great frustrations of working on arm machines vs x86
<pixelherodev>
I don't think EFI is the right solution.
<leeward>
uboot?
<pixelherodev>
I want something more akin to "jump to address X"
<pixelherodev>
I don't like firmware having support for a) filesystems b) loadable modules c) graphics drivers d) etc
<pixelherodev>
It's BS, it's needless complexity, and it's more points of failure
<shakesoda>
if it gets me operating systems actually working, i will take it
<shakesoda>
but it's totally overengineered, for sure
<pixelherodev>
Sure, but you can get that goal without EFI
<pixelherodev>
I want to see x64 machines with BIOS :P
<shakesoda>
the big thing is just hardware discovery stuff i guess
<pixelherodev>
Literally yeah
<pixelherodev>
This isn't the 90s
<pixelherodev>
Every OS can do all the important stuff themselves
<pixelherodev>
They shouldn't be reliant on firmware
<pixelherodev>
It's also why I hate ACPI
<pixelherodev>
ACPI is *neat*, but
<pixelherodev>
That's not really a good reason to use it IMO :P
<pixelherodev>
I take that back
<pixelherodev>
I love ACPI
<pixelherodev>
I hate AML
<ikskuh>
pixelherodev: AT or ATX power? :D
<pixelherodev>
I don't like the idea that OSes need a full freaking VM just for power management
<pixelherodev>
I mean, really?
<pixelherodev>
A turing-complete VM environment... for something that should be static?
<shakesoda>
i will suffer the details if my systems start getting some cross compatible os images
<shakesoda>
i will suffer a lot of horrible, horrible details for that
<shakesoda>
and i will fully agree with you that they are indeed horrible
stripedpajamas has joined #zig
<pixelherodev>
To me, I'd rather not settle like that
<pixelherodev>
Better to take the time to do it right the first time
<pixelherodev>
Even if it means dealing with the awful status quo for a bit longer
<pixelherodev>
gah you've got to be kidding me
<pixelherodev>
libxkbcommon just started segfaulting out of nowhere
<pixelherodev>
Didn't upgrade *anything* but now I can't open a single freaking thing
<pixelherodev>
Rather, it segfaults if I have any *two* programs open???
<shakesoda>
uefi is pretty much what we're going to end up with regardless, i'm fairly sure, since we've already got it and arm moving into more spaces where it applies
<pixelherodev>
Boo
<pixelherodev>
So let's work on a replacement!
<pixelherodev>
I know!
<pixelherodev>
It should just
<pixelherodev>
detect boot drive
<pixelherodev>
Load a specified blob of data off of it
<pixelherodev>
and execute
<shakesoda>
time to convince arm that sbbr should just do that
<shakesoda>
you'll still be unhappy with this, i promise
<pixelherodev>
WHY
<pixelherodev>
WHY WOULD YOU DO THAT
<pixelherodev>
UEFI is bad enough on desktop stuff
<pixelherodev>
Why the bleep would you use it for embedded?!
<pixelherodev>
Ugh
<pixelherodev>
It's like they're trying to out-x86 x86!
<shakesoda>
i think i'll take it over the /entire/ legacy mess that x86 has
<pixelherodev>
I'd much prefer, like
<pixelherodev>
RISC-V
<pixelherodev>
or xtensa
<shakesoda>
i was pretty happy with the uefi available on the pi 3, haven't tried it on the 4
<shakesoda>
everyone directly targets pi though, so it mostly just gets you a boot menu if you want it
Snetry has quit [Ping timeout: 246 seconds]
<shakesoda>
which, well, whatever in this case.
<shakesoda>
it'd be more useful with more ecosystem
Snetry has joined #zig
aerona has quit [Quit: Leaving]
layneson has quit [Ping timeout: 264 seconds]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
layneson has joined #zig
stripedpajamas has quit [Quit: sleeping...]
wootehfoot has quit [Quit: Leaving]
Akuli has quit [Quit: Leaving]
forgot-password has joined #zig
<forgot-password>
Is there a canonical way to create custom build steps? The way I do it right now is just to have a separate Zig file that I add via addExecutable and have it executed on the desired build step. But this gets rather messy, because I have to generate all file paths in the main build.zig and pass them via addArg
<ikskuh>
forgot-password: there's sme "addCustomBuildStep" afaik
<forgot-password>
Say I need to package a dynamic library in some directory structure with some meta information
<forgot-password>
Huh, I'll take a look, thank you
<andrewrk>
pixelherodev, the Function impl (from codegen.zig) is referenced by ElfFile (from link.zig). I think even ElfFile will be replaced by a different abstraction for a C backend. Inside Module where it interacts with anything related to "bin_file" I think will be modified to support an alternate concept of an output file
<andrewrk>
that's where to break the chain. edit the code where Module interacts with "bin_file", to do something else in the case of targeting .c source
saskwach has joined #zig
<shakesoda>
hmmmm, i can't get asm output right now from zig on compiler explorer
<shakesoda>
everything just says no output: objdump returned 1
<leeward>
shakesoda: seems to be working fine for me with the default function (square)
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<shakesoda>
leeward: i can't get it to give me output for anything :(
<shakesoda>
it builds and i get the right program output, but not the dump
<andrewrk>
oh he's in the channel, I should just say squeek502 :)
<squeek502>
hello
<andrewrk>
I suspect for strings it will be even better since AutoHashMap will now decide to store hashes of strings, avoiding potentially costly equality checks
<ikskuh>
wooow neat
<squeek502>
was planning on trying strings as well
<ifreund>
nice!
<shakesoda>
do we know how this compares to other hashmaps elsewhere?
gchristensen has left #zig ["WeeChat 2.6"]
<andrewrk>
shakesoda, no, and that's a good point
<ifreund>
I'm working on a swiss tables implementation so we'll see soon
<ifreund>
lemmi is as well :D
<shakesoda>
i'd be curious to know how it is compared to robin hood or so
<andrewrk>
this is using robin hood
<ifreund>
it's a lot more complex though and might not be a good fit for the standard library
<andrewrk>
the tricks that #5786 uses: * robin hood hashing * separate entries array from indexes array * power of 2 index array length to avoid modulus (that actually made a significant difference, to my surprise)
<ikskuh>
yeah, using bit tricks is still faster
<andrewrk>
* store hash in the entries (optional with a comptime parameter)
<ikskuh>
as it uses way less hardware components
<pixelherodev>
andrewrk: gotcha, thanks
<ifreund>
swiss tables use cool simd stuff
<pixelherodev>
I'd had a few ideas on how to get started, but I figured it was better to delay it a bit and make sure we were on the same page ;)
<ifreund>
and are way nicer to implement in zig than c++ :)
<andrewrk>
what does it use simd for?
<andrewrk>
oh one more trick: * for small (currently <= 8) number of entries, there's no indexes at all, it's just linear scan on the entries ArrayList
<ifreund>
it stores metadata on what entries are in use in part of the allocation, and can use simd to check a hash against 16 slots at once
<andrewrk>
these are sets, and should be using hash maps, but I was worried about all the memory overhead of a table, since there are many decls. but with this optimization that makes hash maps take up only a single pointer sized integer more space than an array list for small entry counts, it's no problem to upgrade these fields to tables
<andrewrk>
plus now iterating over them is as easy as iterating over array lists
<shakesoda>
andrewrk: the mod thing making a big difference reminds me of gpus, heh
<shakesoda>
mod in a shader ends up compiling as something like 31 instructions
<shakesoda>
they're a lot nastier than you'd think
<pixelherodev>
Alrighty, will get started on CBE tonight :D
<andrewrk>
ifreund, I get it now, e.g. you can skip over 16 slots with 1 instruction, knowing none of them contain the entry. this would allow the array to get more full before needing to reallocate
<andrewrk>
neat
<ifreund>
yeah for sure
<andrewrk>
pixelherodev, if it gets too confusing, here's a strategy that I sometimes do when coding: make a branch. make *destructive* changes to the source. e.g. you're doing a CBE, so delete the parts that aren't relevant to CBE. this part is fun :). once you get something working, you look at the diff, and then start restoring the deleted bits, re-integrating them back into the codebase
<ifreund>
this c++ code I'm reading is absolutely drowning in complexity, I think the Zig impl will be far more readable
<pixelherodev>
andrewrk: that hopefully shouldn't be needed
<pixelherodev>
After my last PR, I'm pretty comfortable with stage2
<shakesoda>
i figured there'd be some kind of punishment for abusing the for
<shakesoda>
but instead it's just ugly and nothing else of note
SimonNa has joined #zig
<shakesoda>
i saw this sort of thing in one of the old issues, so i wanted to see what it actually does if you use it.
<jaredmm>
What's the best way to handle cimport redefinition errors when including a header file that includes other (often system) headers with the least amount of manual glue?
<ifreund>
jaredmm: usually it's best to only have one @cImport block in your code base to avoid such errors
<ifreund>
e.g. create a c.zig file with nothing but pub usingnamespace @cImport({ // all the stuf });
<jaredmm>
I knew that wasn't going to get the right answer because of a lack of clarity. When importing certain Windows headers with a single c.zig file, I'll often see redefinition errors for "__".
<jaredmm>
I'm fairly certain this is caused by issues in cimport itself and how some intrinsic functions are handled (three months ago I thought I knew and couldn't resolve it).
<ifreund>
huh, I haven't run into anything like that before
<shakesoda>
that sounds like something i ran into the other month and don't remember what i did with
<jaredmm>
There might be a header on Windows to stop it from happening, but the core of the issue (if my brain remembers almost four months ago, now that I think about it) was that you'd have something like #define __$some_absolute_nonsense
<jaredmm>
The identifier then stops at __ because $ is dumb and you get a bunch of duplicate untranslatable things that aren't relevant to what I'm working on but annoy me anyway.
<jaredmm>
shared\specstrings_strict.h is the Windows header that gets pulled in and causes it.
aerona has quit [Read error: Connection reset by peer]