ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
atk has quit [Quit: Well this is unexpected.]
return0e_ has joined #zig
karlguy has quit [Quit: Leaving]
mnoronha has joined #zig
<scientes>
does zig default to --march=native?
<scientes>
(I noticed this: https://godbolt.org/z/AdVnxg ) the popcnt instruction is SSE4 which is not all x86_64 machines
<andrewrk>
hmm actually it might not be an llvm bug. it might have been an alignment issue which is now fixed. I should try enabling that again.
mnoronha has quit [Ping timeout: 244 seconds]
mnoronha has joined #zig
return0e_ has joined #zig
return0e_ has quit [Remote host closed the connection]
mnoronha has quit [Ping timeout: 245 seconds]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 252 seconds]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 272 seconds]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 252 seconds]
reductum has joined #zig
reductum has quit [Client Quit]
unique_id has quit [Remote host closed the connection]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 268 seconds]
<andrewrk>
welcome back, kristate
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 244 seconds]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 272 seconds]
MajorLag has quit [Read error: Connection reset by peer]
MajorLag has joined #zig
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 252 seconds]
porky11 has joined #zig
porky12 has joined #zig
porky11 has quit [Read error: No route to host]
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 272 seconds]
davr0s has joined #zig
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 244 seconds]
Ichorio has quit [Ping timeout: 260 seconds]
redj has quit [Ping timeout: 252 seconds]
porky12 is now known as porky11
very-mediocre has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<very-mediocre>
Might be silly but am I wrong to want to be able to use `comptime var` outside of the function scope?
<very-mediocre>
The general use case would be to update something that exists at comptime later.
<very-mediocre>
(later = still comptime though)
davr0s has joined #zig
fsateler_ has quit [Quit: ZNC 1.7.1+deb2 - https://znc.in]
fsateler has joined #zig
Hejsil has joined #zig
<Hejsil>
very-mediocre, you could pass a pointer to a some comptime only variable
<Hejsil>
fn a(comptime something: *u8) void
mnoronha has joined #zig
<very-mediocre>
the comptime only variable has to be declared as const though, can't pass a mutable pointer that points to a const, no?
<Hejsil>
comptime var i: u8 = 0; a(&i);
<Hejsil>
Pretty sure this
<Hejsil>
works
<very-mediocre>
let me try :]
<very-mediocre>
well you can't declare "comptime var" in the global scope
<very-mediocre>
it has to be const
<very-mediocre>
which implicitly becomes comptime
<Hejsil>
Aaah, you want a global comptime var
<very-mediocre>
yes
<Hejsil>
Well, nope. Not possible
<Hejsil>
And I'm sure that would get really messy
<very-mediocre>
I agree but it does feel a bit limiting now
<Hejsil>
What are you trying to do?
<very-mediocre>
comptime stuff isn't always set in stone
<very-mediocre>
sometimes you want to provide a library that lets the consumer of the library also do things at comptime
<Hejsil>
Sure, but as with normal global state, it is rare that you actually need it
<very-mediocre>
Well one experiment I was doing which made me notice this, was some comptime interface shenanigans
<very-mediocre>
I found I was doing increasingly complicated things, when it would be much simpler to have a registry at the global scope
<Hejsil>
Might be true
<very-mediocre>
Might also be that there's some obvious better solution that currently eludes me
<very-mediocre>
hm, you're right that it'd get messy to import such a module though
<very-mediocre>
I'm unclear on how zig import works, I'm used to TS/JS right now where the entire module gets imported as a closure
<very-mediocre>
like if I wrote to some hypothetical comptime var, state would probably be lost upon import :/
<Hejsil>
If file_a does @import("std") and file_b does @import("std"), then they'll both share everything from "std". Globals and all
<very-mediocre>
I see
<very-mediocre>
I'm still toying with half baked ideas here.
<very-mediocre>
I have in mind a comptime linked list
<very-mediocre>
to serve as a Set structure
<very-mediocre>
O(n) is not bad for the use cases I am experimenting with. Alas, it can't be done this way.
<MajorLag>
Hopefully we can solve #1291 in the near future and make that sort of thing straight-forward.
<very-mediocre>
That'd go a long way
<very-mediocre>
I thought I was being clever using a linked list to bypass that altogether
<very-mediocre>
I also had a workaround in mind for the lack of programmable types...
<very-mediocre>
Resulting in sort of a binary tree union
<very-mediocre>
So you could conceivably generate a catch-all type for all implementors of an interface, that you could unbox
<Hejsil>
"programmable types"? You mean generating types with comptime?
<very-mediocre>
yeah
<Hejsil>
Alright
<very-mediocre>
What @reify is supposed to be, but I was told that might be too powerful
<very-mediocre>
You could conceivably do like, a union with 2 fields
<Hejsil>
I have an implementation in mind that could do alot of what reify does
<very-mediocre>
1 field = known type
<very-mediocre>
2nd field = a nested version of the same union
<Hejsil>
I'd love to see if you can get that to work
<very-mediocre>
This is all hypothetical, I've yet to try it, but the point was to have a union representing all implementors of an interface so you could pass "Shape" to a function
<very-mediocre>
but then you'd still have to unbox in the function body
<very-mediocre>
What do you have in mind that can do what reify does?
MajorLag has quit [Read error: Connection reset by peer]
MajorLag has joined #zig
davr0s has quit [Read error: Connection reset by peer]
very-mediocre has quit [Ping timeout: 256 seconds]
<halosghost>
andrewrk: do you have a list of data structures / types that you'd like to see in the standard library?
Hejsil has joined #zig
<andrewrk>
halosghost, no. until we get closer to 1.0.0 std lib is inclusionist (as long as the code comes with tests) because it helps test the language
<andrewrk>
closer to 1.0.0 there will be a big std lib audit, and a lot of stuff will be removed (and can be maintained in third party packages)
<halosghost>
cool
<halosghost>
bunch of things I'd like to try my hand at implementing
very-mediocre has joined #zig
<halosghost>
hello, aur/zig-static :D
* halosghost
installs
very-mediocre has quit [Ping timeout: 256 seconds]
Ichorio has joined #zig
darithorn has joined #zig
tom1998 has joined #zig
<tom1998>
Ey up, just asking a quick question - what exactly counts as 'freestanding'? What can I use / not use from the stdlib?
<tom1998>
Can I use the fixedbuffer thread safe allocator if I allocate the actual memory via malloc()?
<andrewrk>
tom1998, zig has lazy top level declaration evaluation - so you can use everything that does not depend on an operating system, down to a fine grained variable / function level
<andrewrk>
if you try to use something that depends on an operating system in freestanding mode, you'll get a compile error. so you can't get bugs by trying to use something from the std lib
<tom1998>
Is there a way to force the compiler to build freestanding even if it normally builds not freestanding?
<andrewrk>
so the sort of questions you are interested in are: "does the fixed buffer thread safe allocator depend on any OS API?"
<andrewrk>
and the answer is no
<tom1998>
i see
<andrewrk>
you want to set some global state so that zig thinks the native environment is freestanding?
<andrewrk>
are you trying to save keystrokes by avoiding typing `--target-os freestanding --target-arch xyz` ?
<andrewrk>
you could use zig build
<andrewrk>
and then just set the target to freestanding in the build script
<tom1998>
nope, i just didn't know the target-os accepted that, thanks
<tom1998>
Not sure if anyone's still here, go another question about building freestanding;)
<tom1998>
So I'm building for a linux target on ARM, but zig doesn't support arm linux, HOWEVER i was under the impression that I could build freestanding & link to libc to interact with the OS
<tom1998>
I'm unsure if i've just misunderstood, I am no compiler guru & I never build anything freestanding
<tom1998>
I'm trying to link to libc with --library c, but I'm getting an error as it's saying it can't find libc
<tom1998>
I'm currently building with --target-arch x86_64 (as I'm not on my ARM machine yet), and --target-os freestanding
<tom1998>
No, i'm not cross-compiling currently, i'm testing a freestanding build on x86_64 first to make sure my program isn't using any OS stuff that it shouldn't be
<tom1998>
then I'm going to either cross compile or compileon the machine later
<andrewrk>
wait, freestanding isn't compatible with libc
<andrewrk>
libc depends on an operating system
<tom1998>
where did I see that said I could compile for arm as long as I called through the c lib and didn't try to use any zig-specific os calls
<andrewrk>
in the readme: "Note that if you use libc or other libraries to interact with the OS, that counts as "freestanding" for the purposes of this table."
<tom1998>
i don't actually want to compile a freestanding program in the sense that i can run it bare metal, i just want to run on arm64, scientes's thing looks like it's failing the builds (?)
<scientes>
tom1998, its just timing out
<andrewrk>
scientes, I'm going to tackle your ARM PR tomorrow
<tom1998>
andrewrk how do I link in libc for arm then, or am i misunderstanding the readma
<andrewrk>
tom1998, you want `--target-os linux --target-arch (one of the arm architectures)`
<tom1998>
it sounds like the readme is saying 'we don't officially support arm/linux, UNLESS you use other libraries to interact with the OS, in which case you're golden'
<andrewrk>
and --library c
<tom1998>
ohhhhhhhh, so I don't actually want --target-os freestanding even though it says freestanding in the table
<andrewrk>
right, your target isn't freestanding, your target is arm. I'll clarify the wording
<andrewrk>
tom1998, and then you need an arm libc to link against. you're on x86_64 so that would be a cross compiled libc