<scientes>
I have a bug in lld that it should use the pc as an offset
<scientes>
when it is in the same binary
<scientes>
its so obvious i can't believe no-one did it
<scientes>
you still get position-independant-code, but without the slowness
<andrewrk>
That's neat
<scientes>
the linker just has to fill in the offset
<scientes>
its a single extra instruction
<emekankurumeh[m]>
I know it's kinda soon but do you have a projected date for the next release cycle?
<scientes>
emekankurumeh[m], llvm 9
<andrewrk>
Yep, check the milestone on GitHub
<emekankurumeh[m]>
i forgot that they sync up
<scientes>
oh two instructions on x86, because x86 doesn't let you set the destination register of add
<andrewrk>
scientes is correct. The date I put there is my prediction of when it will be 1 week after LLVM 9
_whitelogger has joined #zig
companion_cube has joined #zig
<companion_cube>
congrats on 0.4!
hio has quit [Quit: Connection closed for inactivity]
shritesh has joined #zig
<shritesh>
Late to the party but Congratulations!!!
<hryx>
emekankurumeh[m] who told you about the cabbages
<hryx>
(kidding)
<hryx>
shritesh nice work on those fixes for 0.4
<shritesh>
hryx: you too
<hryx>
^_^
<hryx>
next release will be more groundbreaking I'm sure
<shritesh>
Definitely!
<shritesh>
Going through the release notes and I'm like Damn!
<hryx>
so shritesh I know you and I both worked on a lot of formatting issues for this last release (you did more than that too)
<hryx>
what do you have planned for the next release cycle?
<shritesh>
I just went through the issues and tackled the ones that I could understand lol.
<shritesh>
But I do have interest in WASM and GPUs so maybe those?
<shritesh>
Also, what would be the best for the project?
<emekankurumeh[m]>
a spirv backend would pretty cool for writing shaders in zig
<hryx>
shritesh: I know andrewrk is intersted in WASM developers so I totally encourage you to work on that
<shritesh>
I definitely will.
<hryx>
I am working on rewriting the parser as recursive (1729)
<hryx>
this will take a couple weeks, as predicted in the ticket
<shritesh>
emekankurumeh[m]: ..and GPGPU kernels
<shritesh>
hryx: that looks exciting.
<mikdusan>
i was fooling around writing toy parsers and found that i really REALLY like union(enum) for state. works so nice with switch statements.
<hryx>
thanks shritesh, I agree -- pretty much the benefit of this is to make development easier for future developers
<shritesh>
I come from an FP background and when I saw that union(enum) are really sum types, I was sold.
_whitelogger has joined #zig
Hejsil has joined #zig
<Hejsil>
Gratz on the release, zig team and all other contributors!
<scientes>
PARTY!
_whitelogger has joined #zig
<scientes>
mikdusan, i was just going to comment, that for most purposes you never really need to decode utf-8, only validate it
<scientes>
both UTF-32 and zextened utf-8 are 32-bits a character
<mikdusan>
i agree.
develonepi3 has quit [Remote host closed the connection]
<andrewrk>
congrast to you too Hejsil :)
<emekankurumeh[m]>
it might be good idea for someone to make a learnxinyminutes.com tour for zig
<andrewrk>
looks like we got our 15 minutes of fame
fengb has left #zig [#zig]
fengb has joined #zig
<scientes>
oh yeah hacker news front page
<emekankurumeh[m]>
i saw it on hackernews but i don't remember seeing it on reddit
<Hejsil>
andrewrk, just posted an issue to celebrate the release!
<andrewrk>
Hejsil, a perfect end to a release day: more bugs!
<emekankurumeh[m]>
technically that's issue #1214
<emekankurumeh[m]>
i think
<Hejsil>
emekankurumeh, well not exactly. I'm not proposing we embed fields, I'm simply stating that since files are now structs, use should work on structs like it works on files
<Hejsil>
But i guess that is part of the issue you point too
<emekankurumeh[m]>
but wouldn't that lead to embedding fields as well?
<telemach>
many C libraries use prefixes as poor man's namespacing; when i do @cImport in Zig I end up with stuff like soundio.soundio_outstream_begin_write
<andrewrk>
it's funny, the programming language posts with less content get more responses. maybe everybody is still reading the release notes :)
<telemach>
which is totally tolerable, but Terra for example allows you to apply rewrite rule
<telemach>
to remove prefix and you have just proper namespace
<andrewrk>
telemach, generally I import all the C stuff into a namespace called `c`
<Hejsil>
emekankurumeh[m], currently we can have fields at top level, but those are not imported with use. Use only imports declarations
<emekankurumeh[m]>
are the imported symbols "references"? for example if i have `var f` in `a.zig` and `use @import("a.zig")` in `b.zig` would changing `f` in `b.zig` change it in `a.zig` as well?
<Hejsil>
emekankurumeh[m], I would think so, but I'll check real quick
<Hejsil>
Yep, they are "references"
scientes has quit [Ping timeout: 252 seconds]
<emekankurumeh[m]>
andrewrk: regarding hash functions for build caching have you seen meow_hash? https://mollyrocket.com/meowhash
Kingsquee has joined #zig
shritesh has quit []
<daurnimator>
andrewrk: congrats on the release!
shritesh has joined #zig
<shritesh>
Homebrew has zig 0.4.0 now
allana has joined #zig
allana has quit [Read error: Connection reset by peer]
tiehuis has joined #zig
<tiehuis>
andrewrk: think the download page has been reverted to an older on ziglang.org, only showing the 0.3.0 release
<tiehuis>
index.json is still up to date showing 0.4.0
<tiehuis>
ahh darunimator: was actually looking at the aur package right this second
japanoise has joined #zig
<daurnimator>
tiehuis: I'm working on adding it to community right now :)
<tiehuis>
won't you still need the llvm package itself for the headers?
<daurnimator>
tiehuis: yeah got small changes there. trying to figure out how to change it to actually run tests
<daurnimator>
zig doesn't seem to like running tests *before* its installed
<tiehuis>
yeah it can be a bit funny, it should use the std library found relative to the binary anyway but i'd need to confirm that again
<tiehuis>
you could try with --override-std-dir
forgot-password has joined #zig
<tiehuis>
actually, should this should work `./zig build --build-file ../build.zig test-std` as expected in check()
<tiehuis>
choosing the appropriate tests, of course
<forgot-password>
Hey andrewrk, can you add a link to the 0.4.0 release notes on the Homepage in the "Reading and Viewing Material" section?
<tiehuis>
nevermind what i mentioned, didn't have a clean environment
<daurnimator>
tiehuis: it fails with Unable to find zig lib directory
<tiehuis>
alright, looks like it checks for the existence for a zig_lib_dir even when an overriden std dir is specified
<tiehuis>
let me check see if i understand this right and i'm not missing something
<tiehuis>
ahh right it still is required for the include dir (for c headers) and there isn't an explicit option there
tiehuis has quit [Quit: WeeChat 2.4]
very-mediocre has joined #zig
<very-mediocre>
congrats on shipping 0.4.0
<gamester>
Okay guys time to hold me accountable: I've just registered zig-game.com as a temporary domain name for my project. Before zig 0.5 I will have a blog post on there on how zig helped me do x/y/z, I will have code examples from my project to show people what Zig code looks like, I will have screenshots/videos, I will have a WASM light-weight 3D renderer (written in Zig) for online previewing of certain types of mods that my game will eventually
<gamester>
support, and I will have a list of features that I aim to finish before 0.6 to show that this is an active project. When 0.5 is released I will talk about my project for a bit to try to hype Zig, cause it's a crazy good language and people need social proof! Just remember that this is early in the project, it doens't even have a name, and won't be marketed towards gamers any time soon.
hio has joined #zig
<schme245>
cool, looking forward to the blog posts!
<very-mediocre>
gamester: webgl renderer i presume?
forgot-password has quit [Quit: leaving]
<gamester>
very-mediocre: That's a good question. I'm not sure what the state of webGPU is at the moment, if Chrome begins supporting initial versions of webGPU then I might go directly to it, simply because it's closer to Vulkan which is what I'm using.
<gamester>
I'm not really worried about supporting everybody since this is just for viewing mods
<very-mediocre>
main reason I asked is there are currently a lot of very cool software rendering experiments being done lately
<very-mediocre>
i've been itching to do one but i'm swamped with work sadly
<very-mediocre>
zig seems like the weapon of choice for something like that
<very-mediocre>
zig + some blitting backend probably in c (I haven't thought this through yet...)
<Kingsquee>
tfw already have a ton of rust game engine code
<Kingsquee>
tfw zig didn't exist when I started
<Kingsquee>
why is life so cruel
<telemach>
Kingsquee: what's particularly wrong with Rust?
<Kingsquee>
telemach, it is still averse to most compiletime anything
<telemach>
do procedural macros help in any way or am I missing the essence of the problem?
<Kingsquee>
also type-level numerics
<Kingsquee>
telemach, proc macros can't be used in functions
<Kingsquee>
they can be called *like functions*, but are completely useless for anything you'd pragmatically expect to use a proc-macro for, like compiletime string hashing etc
<Kingsquee>
the whole compile time evaluation situation in rust is a cacophony of different kinds of macros, overlimited const fns, and build system invoked rust code
<Kingsquee>
imo it comes from their insistence on making compiletime things a special case to *define*, rather than something to *evaluate* like jai's #run or zig's comptime
<Kingsquee>
also rust has had a bunch of niggling issues that probably won't be much better for any young language, so I'll spare those frustrations
<Kingsquee>
but the fact they broke dynamic library support in a stable release still irks me
<telemach>
huh, i missed that, i mean breaking dl support
<very-mediocre>
maybe silly: I find stuff like this not intuitive `std.io.BufferedInStream(os.File.ReadError)`
<very-mediocre>
there's no explicit indication that it's returning a type
<very-mediocre>
maybe a convention ought to be used, e.g. `std.io.BufferedInStreamT`
<very-mediocre>
+ instantiation happens lated with a chained `.init()`, in another language with say a `new` keyword this ambiguity would be averted preemptively
schme245 has quit [Remote host closed the connection]
<very-mediocre>
maybe extremely silly: I almost want it to be std::io::BufferedInStream<os.File.ReadError>
<daurnimator>
very-mediocre: convention is that if the first letter is caps it returns a type
<telemach>
/Users/rprakapchuk/tmp/zig-libuv/zig-cache/o/Va9QCs88ZDCwrqWsuc1915kvQ6lSsxV3lW3JMIiQlPa5LKPsq8m99pEd6McJitKA/cimport.zig:1752:15: note: referenced here
<telemach>
close_cb: uv_close_cb,
<telemach>
^
<telemach>
trying to use libuv
<very-mediocre>
daurnimator: you're right of course, maybe it's just a bias I have, but I don't find it intuitive
<very-mediocre>
ok I take it back, need do things zig's way
desperek has joined #zig
<desperek>
hi, so are you looking forward to make all the "core" things like os/file etc. have docstrings and then generate docs from that?
schme245 has joined #zig
<Hejsil>
andrewrk, is there a way to get the path to the test executable even if all tests pass. I want to run valgrind on the tests
<Hejsil>
Hmm. Passing --verbose-link is a way to get the test exe path, but then I'll have to cheat the caching system to force a relink
<Hejsil>
Not a big problem, but it would be nice to just have zig test print the path before running all tests
<bheads____>
can you use --outout-dir and --name to control it?
<Hejsil>
I probably can, but I don't really want it to be somewhere is. I just want to have the path to it. zig test already prints the path if a test fails so you can run gdb on it
<tgschultz>
building against C on windows broke for me somewhere between 0.3 and 0.4. What's the equivelent of --kernel32-lib-dir and friends now? is it just --library-path? What about -libc-include-dir? -isystem didn't seem to function as a replacement.
<daurnimator>
the 0.4.0 release notes include a bit about std.ArrayList.shrink.... is that correct?
<gonzus>
Hey. I am trying to compile HEAD on my mac and I get this:
<gonzus>
-- Could NOT find CLANG (missing: CLANG_LIBRARIES CLANG_INCLUDE_DIRS)
<gonzus>
I did to a brew install llvm
<gonzus>
*do
<gonzus>
And clang does work... I think.
<japanoise>
you need the clang development libraries too
<japanoise>
not sure how to do it on mac, unfortunately. what I did was install it from source
<gonzus>
Ah, I see. I was going to say I can compile a hello world program with clang, but ok.
<gonzus>
Blergh... I tried this and it doesn't recognise the option: brew install llvm --with-toolchain
<companion_cube>
is converting a whole project from C to (unidiomatic) Zig, something envisioned?
<scientes>
yes
<scientes>
well, idiomatic
<companion_cube>
I mean, with C pointers at first, then you can edit and use the right pointer type, this kind of stuff?
<scientes>
companion_cube, the point is that you can slowly switch a c or c++ project to zig
<scientes>
exactly
<companion_cube>
ah yeah but I mean a tool to initially turn all .c files to .zig files
<scientes>
its called c-translate
<scientes>
its part of the zig tarball
<companion_cube>
is it supposed to be complete? as in, never failing?
<scientes>
no, it fails on some stuff
<companion_cube>
can I read on the limitations somewhere?
<scientes>
but zig also embeds clang, and can compile c code
<scientes>
Zig uses the C ABI so it can interact with C on a first-class basis
<companion_cube>
yeah but if you're converting a big project, doing it by hand is… a lot of work
<scientes>
the point is that you convert one piece at a time
<scientes>
it gives you a migration path
<scientes>
you don't have to rewrite
<scientes>
you just re-write when you need to change things
gonzus has quit [Ping timeout: 256 seconds]
<scientes>
and you can do that in zig, because of the tools it gives you
<scientes>
there are many things C does very well, and zig isn't trying to change that
<scientes>
it is just trying to be better :)
<companion_cube>
oh well, nevermind then.
<scientes>
companion_cube, never mind on what?
<companion_cube>
on the idea of covnerting from C to zig
donpdonp has joined #zig
<scientes>
zig gives you all the tools to do that
<scientes>
the point is that you would never do it if it had to be done all at once
<donpdonp>
reading through the 0.4.0 while picking my jaw up off the floor. phenominal work! kudos! zig is a breath of fresh air.
<companion_cube>
rust has some tools to do that (converting all at once into unidiomatic rust)
<scientes>
so does zig
<scientes>
just run "zig translate-c"
<scientes>
zig even has c pointers to make it work better
<scientes>
because the improvements zig makes to pointers doesn't work well for c code
<companion_cube>
cool, so what are the limitations of translate-c ? like, is it going to work on a realistic large C project?
<scientes>
I haven't used it in a while
<tgschultz>
the biggest limitation I recall is translating macros
donpdonp has left #zig ["WeeChat 2.0.1"]
<tgschultz>
many will work, more complicated ones often wont
<companion_cube>
that makes sense.
<scientes>
tgschultz, how about falling back to doing translate-c on the pre-processed file?
<tgschultz>
it's improved a lot since I last used it, so anything else I recall is probably obsolete.
<tgschultz>
that should work as far as I know. Last I'd used it it was already really good at non-macro C.
<companion_cube>
nice. the other tricky part, I guess, is how to 'translate' the build system
Zaab1t has quit [Quit: bye bye friends]
<tgschultz>
man, I guess I really haven't been paying attention to recent changes. I had no idea Allocator interface changed.
<scientes>
yeah i noticed
schme245 has joined #zig
<scientes>
i also noticed it makes too many mmap calls
<scientes>
i should fix that
<scientes>
is there a quick way to make an empty slice?
<gamester>
scientes: Here's what the general purpose allocator does that Andrew is working on: (([*]u8)(undefined))[0..0]
<gamester>
that's for a slice of u8
<scientes>
ok i did it with foo.len = 0
<scientes>
but that is better
Zaab1t has joined #zig
<tgschultz>
andrewrk: put me down for a "me too" on #2073
<scientes>
tgschultz, he's got alot on his plat copy-elision and co-routine re-write is blocking alot of things
<companion_cube>
why don't y'all use jemalloc in the mean time?
<scientes>
companion_cube, you can if you want, but zig std lib does not depend on C
<companion_cube>
yeah, not in the stdlib, but as a package :)
<scientes>
there is no package manager yet
<companion_cube>
right, right.
<daurnimator>
companion_cube: you can use jemalloc. or your libc's malloc :)
<daurnimator>
companion_cube: IMO the general purpose debug allocator is more a "something interesting to stream" than a "must have"
<daurnimator>
companion_cube: andrew used to stream things like the copy ellison PR, but there was too much context and quiet periods to make it interesting
<companion_cube>
heh, that's fair
<companion_cube>
I mean, writing an allocator is a pretty good benchmark for a C competitor
<companion_cube>
(that or writing some kind of VM/bytecode interpreter)
Ichorio has joined #zig
<daurnimator>
companion_cube: note that the allocator isn't meant to be fast or optimal; but be able to catch all sorts of bugs automatically. for production usage you'd use libc or jemalloc or something
<companion_cube>
yeah (also I think jemalloc has similar features for safety)
<scientes>
daurnimator, not really
<daurnimator>
scientes: the general purpose debug allocator has a *lot* of emphasis on the "debug".
<scientes>
zig having allocator passed is great, because many things call for differn't type of allocators, which means companion_cube is missing the point
<daurnimator>
companion_cube: scientes: ^ that is also true
<scientes>
daurnimator, it should also allow tagging memory allocations so you can know how much memory differn't data structures are using
<companion_cube>
yeah that's pretty exciting to have custom allocators everywhere
<daurnimator>
companion_cube: e.g. for a http server, I would expect to see per request arenas
<scientes>
like for a compiler using a arena allocator is way better than malloc/free
<scientes>
its way faster
<scientes>
and uses less memory
<daurnimator>
usually you only see that in highly optimized servers and games; in zig its just a normal day
<scientes>
daurnimator, and not using a hash table, but a rb tree, to avoid the DOS attack
<scientes>
or a cryptographic hash table
<daurnimator>
scientes: huh?
<daurnimator>
scientes: for what exactly?
<daurnimator>
I'm still exicted by maple trees to replace all red black trees
<daurnimator>
I'm on super limited internet right now, so can't look at video
<scientes>
Future improvements to the XArray may make this the only data structure we need, replacing linked lists under all circumstances, the rbtree and even hash tables.
<daurnimator>
scientes: oh I remember that "attack". the solution was pretty much to use a random seed to xor with your hash so that it's unpredictable
<scientes>
but that isn't a complete solution
<scientes>
if you have to make sure that you don't have O(n^2) behavior you have to use a balanced tree
<daurnimator>
it is along with other mitigations normally in http servers.
<scientes>
Donald Knuth said that decades ago
<scientes>
i've met people that say that hash tables are O(nm), these people are abusing asymptotic notation
<daurnimator>
usually headers are e.g. max 4KB. that isn't enough to probe out the random seed. which means that a per-hash table seed is entirely sufficient.
<scientes>
kind of ticks me off
<scientes>
these people usually have more education than me
<scientes>
yeah, but hash tables are O(n^2), end of story
<strmpnk>
I've watched a good number of LCA videos but not this one. youtube-dl'ing it for later.
<scientes>
its still O(n^2). thats the upper bound that you will hit if it is all collisions
<daurnimator>
scientes: to quote my link: A main invariant of these tables is that, if an element is not in its main position (i.e. the 'original' position that its hash gives to it), then the colliding element is in its own main position.
<companion_cube>
unless you have real-time constraints, hash maps are… fine?
<scientes>
companion_cube, correct, they are pretty good in the average day
<scientes>
but for real-time systems they should not be used
<daurnimator>
in reality it turns out that cache line behaviour has far more effect on lookup times than anything else
<scientes>
yes but that is still a constant multiplier
<scientes>
even if very large
<daurnimator>
no.
<scientes>
it has an upper bound
<scientes>
same with page table lookups
<daurnimator>
IIRC the upper bound is something around the amount of memory in your computer. If you have more items in your hash table than memory in your computer... I want your hardware
<scientes>
no, i was talking about cache lines and page tables
<scientes>
hash tables are O(n^2), cache and paging is not
<companion_cube>
why O(n^2) and not O(n), btw? in case of terrible hash function
<daurnimator>
scientes: I can't recall the exact findings right now. but essentially within a cache line the next accesses are free; and then within a page it's essentially free; and then within a TLB miss it's essentially free. as our hardware these days only have 3/4/5 levels of page tables, you only have 5 answers to how long does it takes.
<scientes>
companion_cube, because you cannot guarantee that every key is a hash collision
<scientes>
*is not
<scientes>
O() is the UPPER bound
<scientes>
not the average
<companion_cube>
even then, the hashmap is just a linked list or a linear array lookup
<companion_cube>
I don't see where the ^2 comes from
<daurnimator>
scientes: following my logic from above: the upper bound is 5 TLB misses.
<bheads____>
if I remember it randomly picked an index from the source list, and appeneded it to the end of the dest array O(n) then checked if it was sorted O(n), repeat till sorted...
<bheads____>
so really its O(2n^R)
<bheads____>
which is just O(n^m)
<scientes>
it is ironic that that makes it a more complicated algorithm
<scientes>
because generating random numbers is hard
<bheads____>
now it makes me think of an even dumber one, hashmap with a random hash generator
<companion_cube>
that'd be plain incorrect, not just inefficient
<bheads____>
right, normally you never get anything back, but sometimes you get wrong data
<bheads____>
makes it fun!
<bheads____>
okay I need to get back to fixing other peoples websites... sigh....
<scientes>
bheads____, go calls rand() in its hash function
<companion_cube>
surely you mean, it initializes its hashmaps with a random seed?
<scientes>
nope, read the blog post
<companion_cube>
ahah ok, it makes only sense for nan
<companion_cube>
that's such a bad corner case though
<companion_cube>
(and yeah, storing nan as a key in a hashtable is… ugh)
Sahnvour has joined #zig
<Sahnvour>
hi, congrats everyone on the release!
<bheads____>
they must hash the kay and use that was the seed
<emekankurumeh[m]>
scientes: I know that is actually O(log n), but the 32 means that in practice is practically O(1)
<scientes>
i just noticed that editors number lines from 1, instead of 0
<scientes>
i guess it makes sense
<scientes>
is there any @fieldParentPtr() stuff in zig stage1, cause i'm getting 8 where a pointer should be
wootehfoot has joined #zig
<tgschultz>
my old code is failing in the strangest ways in 0.4.0. Most of it is in dire need of rewriting anyway so I should probably just throw it all out.
<scientes>
ahh the protonode was never populated, and contains junk
ShrewdSpirit has joined #zig
schme245 has quit [Remote host closed the connection]
<ShrewdSpirit>
Hello. What are the requirements for zig compiler to compile? I'm aiming to use the compiler in an UEFI application so the application is self hosted
<scientes>
llvm and ld is about it
<scientes>
I am not a fan of UEFI, but whatever floats your boat
<scientes>
andrewrk, 0.4.0 is now on the download page anymore
<scientes>
*not
<ShrewdSpirit>
BTW I just downloaded the 0.4.0, like an hour ago
<scientes>
you can download it, but its not on the download page
<ShrewdSpirit>
So I assume I can't use the compiler in UEFI :(
<ShrewdSpirit>
as long as zig isn't self hosted
<scientes>
zig will depend on llvm and lld for the foreseeable future
<scientes>
thats the master build, not the tagged build
<ShrewdSpirit>
What's the difference?
<scientes>
nothing right now
<scientes>
but the release notes are not there either
<ShrewdSpirit>
Oh
<andrewrk>
oops, forgot to update src/download/index.html
<andrewrk>
well that's rather unfortunate
<andrewrk>
all this traffic and no links
<andrewrk>
fixed
<bheads____>
andrewrk, were you able to celebrate last night?
shritesh has joined #zig
<gamester>
you could put a link to the 0.4 release notes under the homepage's "Reading and Viewing Material" as you've done before
<scientes>
ugggh, debugging takes so much time
<andrewrk>
bheads____, yes, my girlfriend took me out to dinner
<andrewrk>
gamester, good idea, done
<daurnimator>
andrewrk: nice :)
<daurnimator>
andrewrk: make sure you try and keep to a business-like schedule despite working by yourself
<andrewrk>
I do. I wake up to an alarm every day
<daurnimator>
looks like we just fell off the HN frontpage
<scientes>
ok, i verified that this bug I'm looking at is not my bug...
<gamester>
I think it was a while ago daurnimator
<daurnimator>
gamester: was last item on front page for a while; then one refresh it was suddenly down at 81.
<daurnimator>
HN has some.... interesting... heuristics for what gets to stay on the front page
<daurnimator>
in this case it may have coincided with the west coast of the US going on lunch break
<daurnimator>
*east coast
<gamester>
It's crazy how curated it the HN front page is, I see things magically demoted all the time even when it's very popular, and that's just from browsing HN for the last 2 days. They didn't do that to Zig, but they did it for some J language that was up there at the same time. This is off topic though.
<scientes>
oh wow, it was that simple
<daurnimator>
gamester: on one hand; yes its quite curated; on the other: it's very subject to waking/break/sleep times of various timezones
<scientes>
andrewrk, should we introduce Linux's C version of @getParentPtr() into stage1, or should we fix AstNode to not need it?
<scientes>
cause i just found a bunch of code that thinks AstNode works like IrInstruction with the subtypes having IrInstruction base
<scientes>
*fieldparentptr
<daurnimator>
@fieldParentPtr needs the 'fixed' proposal ASAP IMO.
<scientes>
daurnimator, ?
<scientes>
fieldParentPtr is great
<scientes>
daurnimator, please explain?
<scientes>
the only problem with it I've heard it is that is screws up strict aliasing guarantees
<andrewrk>
scientes, "fixed" proposal is a way to note that a struct field is supposed to never be copied
<andrewrk>
if done right, with no-copy semantics, should remove one of the last footguns from zig
<daurnimator>
it's probably the most common footgun I see in zig-first code
<andrewrk>
yeah it's a big problem
<scientes>
oh, i'm use to dealing with that in C, so i didn't question if it could be fixed
<scientes>
you mean copying, instead of using a pointer, right?
<daurnimator>
scientes: 1. annotate a field with "this can't be copied; you may only deal via reference". 2. fieldParentPtr only works with fields with the prior annotation.
<scientes>
yeah thats a good idea
<scientes>
does it fix the strict aliasing problem?
<daurnimator>
no. strict aliasing is a separate problem
<halosghost>
but, iirc, strict aliasing isn't even a problem in zig
<daurnimator>
it does fix the common issue of e.g. passing an allocator by value
wootehfoot has quit [Ping timeout: 268 seconds]
<scientes>
my rb.zig uses @fieldParentPtr because it is the best way to do it
<scientes>
halosghost, it isn't turned on, but it would be nice to do so in the future
<halosghost>
scientes: what isn't turned on?
<andrewrk>
halosghost, see my link
<halosghost>
ah
<daurnimator>
scientes: in zig, when you pass a variable, it's not defined if it's by value or by reference.
<halosghost>
andrewrk: I was thinking about the fact that (as that link mentions), all aliasing is allowed
<companion_cube>
so if you want reference semantics, you pass a pointer, right?
<daurnimator>
companion_cube: if you pass a pointer, it's not defined whether you get a pointer, or a pointer to a pointer :)
<daurnimator>
i.e. passing a pointer? the pointer is the value. it's not defined if it's by value or by reference.
<companion_cube>
I mean, sure, but at least you can be sure you can modify the parameter
<scientes>
aliasing should be done at some point in some fashion
<companion_cube>
(or its fields, or whatever)
<daurnimator>
companion_cube: correct.... assuming you don't want to e.g. modify the pointer
<daurnimator>
companion_cube: or find the pointer as a member in another struct....
<companion_cube>
yeah I just meant, if you want to pass a struct by reference to modify its content, you can just pass a pointer to it
<companion_cube>
like in C, really
shritesh has quit [Quit: Segmentation Fault]
shritesh has joined #zig
<daurnimator>
companion_cube: yep. one thing I sometimes forget is that all parameters in zig are 'const'.
wootehfoot has joined #zig
moo has quit [Ping timeout: 245 seconds]
Zaab1t has quit [Quit: bye bye friends]
jfo has joined #zig
ManDeJan has joined #zig
fsateler has joined #zig
<ManDeJan>
Hi, what is the Zig equivalent of "void *" in C? Is there a way I can make a function that accepts a slice of any type and then convert it to a slice of u8 with @sliceToBytes?
fsateler has quit [Read error: Connection reset by peer]
desperek has joined #zig
<andrewrk>
hi ManDeJan, strictly speaking the equivalent is *c_void
<andrewrk>
however if you're not interacting with C code, there is probably a better way to do what you're trying to do
<daurnimator>
ManDeJan: that's something I"ve brought up before... zig code often uses usize in place of such a thing
fsateler has joined #zig
<ManDeJan>
I'm not trying to interact with C code :)
<daurnimator>
andrewrk: ^^ I've noted this before during your live streams of the debug allocator around mprotect
<andrewrk>
if you're dealing with raw memory addresses, usize is a good type
<andrewrk>
I doubt this is related to ManDeJan's use case
<daurnimator>
andrewrk: one special case being align annotations
<andrewrk>
true
<daurnimator>
align(16) usize
<ManDeJan>
I'm making a hash function and I want to accept a slice of every type but then iterate over it as a slice of u8
<ManDeJan>
I think thats what I want anyway
<daurnimator>
should `align(16) usize` be valid? or should it be `align(16) *c_void`
<andrewrk>
huh, now that I'm looking I don't think the `var` parameter type is explicitly documented
<andrewrk>
ManDeJan, make your parameter type `var`. that lets it be any type
<daurnimator>
ManDeJan: you probably want to @ptrCast to *u8
<ManDeJan>
andrewrk, Does that generate a different function every time I call the hash function with a different type?
<andrewrk>
ManDeJan, yes
<daurnimator>
ManDeJan: at comptime? yes AFAIK.
<daurnimator>
/bed
<ManDeJan>
Is there a way to accept any type of pointer and a length so that it doesn't generate multiple functions?
<andrewrk>
accept a `[]const u8` and then do @sliceToBytes at the callsite
<ManDeJan>
I'll try that, thanks (:
jjido has joined #zig
<tgschultz>
andrewrk, there's still no way to specify the alignment of a struct, right?
<companion_cube>
I'm mostly curious about your plans (#1194 I guess?)
<companion_cube>
(it's exciting for stuff like encoding recursion, to me, not just IO)
<andrewrk>
yeah. for starters coroutine function pointers won't be supported in the first version
<companion_cube>
(you can traverse a tree with a coroutine, and with a local allocator it should be super efficient)
<andrewrk>
so the coroutine function has to be comptime known to call it
<andrewrk>
and instead of all coroutines being generic and using an allocator to allocate and destroy their own frame, the frame is provided to the coroutine when it is called
<companion_cube>
does it have an internal state that is stored in the allocator?
<andrewrk>
allocators will no longer be coupled to coroutines in any way
<companion_cube>
ah! I've wondered, could the state (a tagged union?) be named?
<companion_cube>
that'd be most explicit
<companion_cube>
(so you can store it where you want)
<andrewrk>
yes there will be a way to refer to the type of a specific coroutine's frame
<andrewrk>
so you could put it, e.g. statically, or in a struct, or allocate it explicitly, however you want
<companion_cube>
sounds good!
<andrewrk>
but if you do: var x = coroutineFn();
<companion_cube>
no magic, very explicit
<andrewrk>
then x has the data; it's in the current stack frame (or coroutine frame)