nikki93 has quit [Read error: Connection reset by peer]
sjd has quit [Ping timeout: 260 seconds]
nikita` has quit [Ping timeout: 264 seconds]
kushalp has quit [Ping timeout: 244 seconds]
kwilczynski has quit [Ping timeout: 272 seconds]
nikita` has joined #zig
sharpobject has quit [Ping timeout: 260 seconds]
kwilczynski has joined #zig
rtpg has quit [Ping timeout: 264 seconds]
nikki93 has joined #zig
procnto has joined #zig
tracernz has quit [Ping timeout: 244 seconds]
r0bby_ has joined #zig
r0bby has quit [Ping timeout: 272 seconds]
r0bby_ is now known as r0bby
gonz_ has quit [Ping timeout: 260 seconds]
hnOsmium0001 has quit [Ping timeout: 265 seconds]
rtpg has joined #zig
tracernz has joined #zig
kushalp has joined #zig
gonz_ has joined #zig
hnOsmium0001 has joined #zig
WilhelmVonWeiner has joined #zig
ur5us has joined #zig
WilhelmVonWeiner has quit [Quit: leaving]
rowbee has quit [Remote host closed the connection]
rowbee has joined #zig
xackus has joined #zig
jukan has joined #zig
xackus has quit [Ping timeout: 260 seconds]
jukan has quit [Ping timeout: 264 seconds]
<pixelherodev>
Even I intend to support zig cc :P
<pixelherodev>
(just not with llvm :)
jukan has joined #zig
jukan has quit [Ping timeout: 265 seconds]
jukan has joined #zig
gazler has quit [Read error: Connection reset by peer]
sjd has joined #zig
decentpenguin has quit [Ping timeout: 256 seconds]
squeek502 has joined #zig
v0idify has quit [Ping timeout: 268 seconds]
decentpenguin has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
decentpenguin has quit [Ping timeout: 260 seconds]
r0bby has quit [Ping timeout: 265 seconds]
r0bby has joined #zig
squeek502 has quit [Ping timeout: 240 seconds]
squeek502 has joined #zig
jukan has quit [Ping timeout: 240 seconds]
<companion_cube>
Will it be part of the spec then?
cole-h has quit [Ping timeout: 246 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
the language spec governs the language, not the toolchain
jukan has joined #zig
_whitelogger has joined #zig
decentpenguin has joined #zig
jukan has joined #zig
jukan has quit [Ping timeout: 256 seconds]
sord937 has joined #zig
gazler has joined #zig
gazler has quit [Client Quit]
<rtpg>
Is there a rule of thumb regarding @cInclude @cImport groupings? is it like "if these are referencing stuff within each other they need to be included together"?
<leon-p>
Is there something like Cs getline() in std? something that puts a single line from stdin into an allocated buffer. I only found functions that have a max_length arguement, but my use case is for arbitrarily long lines, so those are probably not what I want.
<g-w1>
make max_len std.math.maxInt(usize)
jukan has quit [Ping timeout: 260 seconds]
<leon-p>
That is what I have done currently to get the project working. But isn't setting max_length to a very high number, even if it is considerably larger than any realistic input line will ever be, just a hack?
jokoon has quit [Quit: Leaving]
<dutchie>
you are going to have trouble trying to store a line longer than std.math.maxInt(usize)
<dutchie>
even if you somehow don't run out of memory, indexing is going to get weird, so you'll probably need multiple buffers anyway
<dutchie>
it's not a hack, just reflecting the fact that real computers do have actual limits
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
jokoon has joined #zig
<g-w1>
im pretty sure the c function would break if it went above the limit, so zig makes it explicit
<leon-p>
i see, hadn't considered it from that angle, thanks!
earnestly has joined #zig
Akuli has joined #zig
waleee-cl has joined #zig
donniewest has joined #zig
mmkarakaya has quit [Quit: Ping timeout (120 seconds)]
wilsonk has quit [Read error: Connection reset by peer]
wilsonk has joined #zig
jukan has joined #zig
kbd has joined #zig
Flaminator has joined #zig
nvmd has joined #zig
jokoon has quit [Quit: Leaving]
hnOsmium0001 has joined #zig
dfrey has joined #zig
jukan has quit [Ping timeout: 265 seconds]
<dfrey>
Hi. I'm new to Zig, but I'm an experienced C programmer. I'm reading this section (https://ziglang.org/documentation/0.7.1/#Global-Variables) and I'm a bit confused. The S.x variable is behaving like a function static variable in C, but I don't really understand why. So why is the lifetime of S longer than a single execution of the foo function?
<ifreund>
indeed, S is a type
<ifreund>
and x is a global variable in the namespace of S
<ifreund>
if you instantiate the type S and make x into a field, it would be local to the function and return the same result every time: https://0x0.st/--u5.txt
<ifreund>
dfrey: here's a possibly better explanation, the variable S is indeed local to that function, but the type value it holds is gloabal as all types ar
<ifreund>
*are
<Gliptic>
how would I go about getting the type of a struct field, I suppose I could do @TypeOf(@as(Struct, undefined).field) or something silly like that
<dfrey>
const S1 = struct { var x: i32; }; const S2 = struct { x: i32; }; So is it correct to say that x is a variable associated with the type for S1 and a variable associated with an instance for S2?
<Gliptic>
is there a nicer way
<ifreund>
dfrey: well, the second won't compile, you need a comma to make a field: const S2 = struct { x: i32, };
<ifreund>
but yes that is correct
<dfrey>
thanks
<ifreund>
Gliptic: you could do std.meta.fieldInfo(MySruct, .field_name).field_type
<ifreund>
that's less hacky but not really more concicse
<Gliptic>
right, I forget about std.meta
<g-w1>
the first wont compile either since you need an = when declaring variables
<ifreund>
right, zig requires you to initialize all variables, even if just to undefined
stilbruch has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
jukan has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
notzmv has joined #zig
a_chou has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
a_chou has quit [Remote host closed the connection]
frett27 has joined #zig
ur5us has joined #zig
kbd has joined #zig
xyproto has quit [Ping timeout: 264 seconds]
sord937 has quit [*.net *.split]
nycex has quit [*.net *.split]
ur5us has quit [Ping timeout: 264 seconds]
xyproto has joined #zig
wilsonk has quit [Ping timeout: 272 seconds]
cole-h has joined #zig
nycex has joined #zig
ur5us has joined #zig
jukan_ has joined #zig
sord937 has joined #zig
jukan has quit [Ping timeout: 260 seconds]
jukan has joined #zig
jukan_ has quit [Ping timeout: 272 seconds]
xackus has joined #zig
v0idify has joined #zig
ur5us_ has joined #zig
v0idify has quit [Remote host closed the connection]
v0idify has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
sord937 has quit [Quit: sord937]
jukan_ has joined #zig
jukan has quit [Ping timeout: 256 seconds]
dputtick has quit [Ping timeout: 260 seconds]
dch has quit [Read error: Connection reset by peer]
nikki93 has quit [Ping timeout: 265 seconds]
dch has joined #zig
kwilczynski has quit [Ping timeout: 272 seconds]
nikki93 has joined #zig
dputtick has joined #zig
kwilczynski has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
notzmv has quit [Ping timeout: 260 seconds]
Akuli has quit [Quit: Leaving]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
zags has joined #zig
<zags>
Hey. I know it's prolly too late now, but was adding support for general union types and flow-sensitive typing ever discussed? By flow-sensitive typing, I mean automatic narrowing based on type tests so you don't need additional casts.
<ifreund>
I'm not sure I understand what you mean, how is that different from the tagged unions we have today?
<ifreund>
Gliptic: you're missing a const, this would work; `const slice: []const []const u8 = &[_][]const u8{ "test" };
<Gliptic>
you'd think so, but no
<Gliptic>
error: expected type '[][]const u8', found '[]const []const u8'
<ifreund>
Gliptic: that's an issue with how you are using the slice then...
<ifreund>
do you really need the outer one to be mutable?
<Gliptic>
hm, ah, the const was missing from the parameter type I pass it to
nvmd has quit [Quit: Later nerds.]
<zags>
ifreund: lol, I did try that but got errors and starting trying increasingly complex things. Turns out I had try x catch ..., removing try works like a charm.
<zags>
Seems like the compiler could say "did you mean to use catch here?" instead of expected error union type, found 'Mod.SomeStruct()'
<zags>
It's not wrong, just some clang-style magical insightful errors would be helpful
<ifreund>
oh yeah, the stage 1 compile error messages are pretty bad
<zags>
I see
<ifreund>
as you might imagine, there's not much motivation to improve them as stage2 is the long term goal
<zags>
so stage1 will be nuked long term?
<zags>
not sure how it's structured
<ifreund>
indeed, stage1 is the C++ implementation that is currently used to build zig
<zags>
ohhhh
<ifreund>
large parts of the compiler frontend are already self-hosted though
<zags>
so it'll be self-hosted
<zags>
right
<ifreund>
so your zig binary is actually a mix of zig and c++ code
<ifreund>
when stage2 codegen is feature complete the C++ implementation can be deleted
<zags>
I see, yeah that must be a torn in the eye for zig compiler devs
<ifreund>
there's also a lot of design issues in stage1, which is why it's so slow and such a memory hog
<zags>
on larger things, the part that emits llvm is slow as well it seems - will that be improved?
<zags>
i guess llvm isn't as fast as it used to be
frett27 has quit [Ping timeout: 272 seconds]
<g-w1>
stage2 wont depend on llvm
<g-w1>
its optional
<zags>
Is the plan to reimplement optimizations, or is that where you switch to llvm (for release builds) ?