KIMI_0881 has quit [Remote host closed the connection]
frett27_ has quit [Ping timeout: 272 seconds]
joaoh82 has quit [Remote host closed the connection]
joaoh82 has joined #zig
a_chou has joined #zig
joaoh82 has quit [Ping timeout: 256 seconds]
a_chou has quit [Remote host closed the connection]
cole-h has joined #zig
hsh has quit [Quit: Connection closed for inactivity]
hlolli_ has joined #zig
hlolli__ has quit [Ping timeout: 272 seconds]
joaoh82 has joined #zig
a92 has quit [Remote host closed the connection]
a92 has joined #zig
joaoh82 has quit [Ping timeout: 264 seconds]
a92 has quit [Ping timeout: 240 seconds]
moinstar has quit [Quit: Leaving.]
moinstar has joined #zig
xackus_ has joined #zig
joaoh82 has joined #zig
joaoh82 has quit [Remote host closed the connection]
joaoh82 has joined #zig
hlolli_ has quit [Ping timeout: 272 seconds]
<andrewrk>
marler8997, with the latest commit to zig-window it is additionally working on musl based linux distros
tetsuo-cpp has joined #zig
xackus_ has quit [Ping timeout: 240 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
xackus_ has joined #zig
cole-h has quit [Ping timeout: 246 seconds]
Iolen has joined #zig
Iolen has quit [Quit: Leaving]
dumenci has joined #zig
joaoh82 has quit [Ping timeout: 240 seconds]
gpanders has quit [Ping timeout: 265 seconds]
gpanders has joined #zig
joaoh82 has joined #zig
gpanders has quit [Ping timeout: 246 seconds]
joaoh82 has quit [Ping timeout: 264 seconds]
gpanders has joined #zig
gpanders has quit [Ping timeout: 240 seconds]
srgpqt[m] has quit [Quit: Idle for 30+ days]
frett27_ has joined #zig
koakuma has joined #zig
<ikskuh>
andrewrk: can i somehow use Builder.addWriteFile to create a Package?
<koakuma>
Excuse me, I'm having some weird issues with floating point values on sparc64
<koakuma>
Found out that FP values would compile down to wrong constants in assembly when compiled natively on a sparc64 machine, but compiles down correctly when cross-compiled using an x64 machine
<koakuma>
Zig uses strict -std=c99 to compile files, and it, for some reason, makes sys/types.h not include endian.h
<koakuma>
So we don't get the endianness macros
<koakuma>
It just probably happen to work on LE machines because, for reasons that I don't know why, the lack of macros results in the #if in parse_f128.c to take the LE branch
<TheLemonMan>
does it pick the correct macros if you explicitly include it?
frett27 has joined #zig
rzezeski has joined #zig
<koakuma>
If I explicitly include endian.h, then yes, the macros seem to be picked correctly
<TheLemonMan>
oh dog, undefined macros default to zero
<TheLemonMan>
that's why `__BYTE_ORDER == __LITTLE_ENDIAN` is always taken
wootehfoot has joined #zig
<koakuma>
It seems to parse correctly now
<koakuma>
I'll prepare a PR for this
gpanders has quit [Ping timeout: 256 seconds]
gpanders has joined #zig
wootehfoot has quit [Ping timeout: 256 seconds]
gpanders has quit [Ping timeout: 246 seconds]
<koakuma>
Wait, seems like BSD doesn't have an endian.h?
wootehfoot has joined #zig
<TheLemonMan>
its sys/endian.h there iirc
jpe90 has joined #zig
riba has joined #zig
<koakuma>
Ah, thanks
rhencke has joined #zig
<rhencke>
the documentation for the zig build system mentions that it can help with "surfacing build configuration as comptime values by providing a file that can be imported by Zig code." does anyone have any examples of what such a file would look like?
<ifreund>
rhencke: the file is created automatically when you call addBuildOption()
<rhencke>
ifreund: ah! thank you!
<ifreund>
you can then import and access the options with @import("build_options")
<rhencke>
i thought i was the one who had to provide the file, haha
<ifreund>
yeah, documentation is far from complete for the build system :/
<rhencke>
appreciate the help :)
waleee-cl has joined #zig
oats is now known as grogu
<ifreund>
no problem!
jpe90 has quit [Quit: WeeChat 2.9]
grogu is now known as oats
cole-h has joined #zig
koakuma has left #zig [#zig]
jpe90 has joined #zig
Akuli has joined #zig
lucid_0x80 has quit [Ping timeout: 240 seconds]
lucid_0x80 has joined #zig
dumenci has joined #zig
lucid_0x80 has quit [Ping timeout: 256 seconds]
Pistahh has joined #zig
riba has quit [Ping timeout: 240 seconds]
cole-h has quit [Ping timeout: 256 seconds]
g-w1 has quit [Ping timeout: 256 seconds]
g-w1 has joined #zig
frett27 has quit [Ping timeout: 272 seconds]
remby has joined #zig
moo has joined #zig
Jeanne-Kamikaze has joined #zig
moo has quit [Client Quit]
wootehfoot has quit [Quit: Leaving]
hnOsmium0001 has joined #zig
dumenci has quit [Ping timeout: 264 seconds]
rhencke has quit [Remote host closed the connection]
_whitelogger has joined #zig
Jeanne-Kamikaze has quit [Ping timeout: 240 seconds]
hlolli_ has joined #zig
jpe90 has quit [Quit: WeeChat 2.9]
remby has quit [Quit: remby]
ur5us has joined #zig
hlolli__ has joined #zig
hlolli_ has quit [Ping timeout: 260 seconds]
remby has joined #zig
dddddd has quit [Quit: dddddd]
jjsullivan1 has joined #zig
jpe90 has joined #zig
dddddd has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
reductum has joined #zig
<remby>
all current documentation is on the site at the Documentation link?
<hlolli__>
I'm getting a bit tripped out with struct consts. I feel it's a happenstance that expression like ''const s: S = S{.a: ?u8 = null,}; s.a = 1;'' throws ''error: cannot assign to constant''. If a pointer to a struct is a const, does it mean that its fields are immuteable?
<ifreund>
no, but you don't have a pointer to a struct there you have a struct value
<andrewrk>
hlolli__, in this code example, the storage provided by `s` is immutable
<hlolli__>
andrewrk, good to hear, that's how I'm understanding const. So to be more concrete in the current error Im fighting, I have a setter function, wich I wall from a struct concretion which is a const pointer.
<ifreund>
hlolli__: there you have a constant pointer
<ifreund>
const foo: *u8 is not the same as const foo: *const u8
<ifreund>
you would have to use `self: *Self` there
<hlolli__>
if I change ''self: *const Self'' to ''self: *Self'' the caller which is a const pointer fails, because it's a const. I mean I can change it all to var, but it would be a lot of refactoring.
remby has quit [Quit: remby]
<daurnimator>
hlolli__: refactoring that probably needs to happen if you're trying to modify things you declared as `const`?
a_chou has quit [Quit: a_chou]
<hlolli__>
the pointer, which is the address in memory where the struct is stored isn't changing by setting a field?
<ifreund>
no, the pointer isn't changing but the data being pointed to is
<ifreund>
which is what the const there is refering to
<ifreund>
the pointer itself is implicitly const as function parameters are always const
ur5us has quit [Ping timeout: 264 seconds]
<hlolli__>
good to know, so I understand it correctly, that when I declare a const like this ''const s: S = S{.a=0}'', the field .a is from this concrecion immutable?
<ifreund>
the entire struct is immutable and stored as a value in s
<ifreund>
there is no pointer involved there
<hlolli__>
this differs from c then, in that there isn't a place in memory for the whole struct?
<ifreund>
structs are semantically values in C as well
<ifreund>
arrays are where zig and C differ in that regard
earnestly has quit [Ping timeout: 240 seconds]
<hlolli__>
sizeof(Struct) is always allocated in c afaik. So then I modify let's say field foo.bar, the address of foo[0] is the same but the value of foo[0] + offsetTobar is changed.
<hlolli__>
anyway, I was never good in C, so I may be wrong here :). Just tripping me out. Especially doing a lot of javascript. Where 'const a = {}; a.b = 2' is totally fine.
ur5us has joined #zig
<hlolli__>
but at the same time ''const a = {}; a = "no";'' fails.
<ifreund>
yeah that's not how C works unless I misunderstand what you're saying
<ifreund>
and I have no idea how javascript works so I'll take your word for it :P
<hlolli__>
is there a lot of optimization I'd lose in using vars instead of const?
<ifreund>
const isn't guarenteed to be any faster at all
<andrewrk>
zig works best if you treat local variables as mostly SSA, with a few mutable stuff thrown in
<ifreund>
and that's besides the point really, if you need to modify something it needs to be mutable
<hlolli__>
of the small amount of documentation/tutorial material I read, vars seem to be discouraged, but this nuance isn't pointed out. Perhaps it's just javscript developers that this trips out :)
<ifreund>
well, you should use const when you can, but often you'll need to mutate something
<hlolli__>
true, but the fact that const is all encompassing on the value, and not just the top level. Like var value within const, in most langugaes I use there's something like that.
<ifreund>
that's how it works with pointers
<ifreund>
i.e. ''const foo: *u8'' is a constant pointer to a mutable u8
<hlolli__>
''const foo: *const u8'' is just the same as ''const foo: *u8
<hlolli__>
?
xackus_ has quit [Ping timeout: 264 seconds]
<ifreund>
no, the first is a constant pointer to a constant u8
<ifreund>
the second is a constant pointer to a mutable u8
<hlolli__>
ahhhhhhh, THERE IT IS :D finally
<hlolli__>
ok that's where I'm doing things wrong. And I felt I was using const pointer all time on variable content.