Bernstein has quit [Remote host closed the connection]
xackus_ has quit [Ping timeout: 252 seconds]
bitmapper has joined #zig
zenkuro has quit [Ping timeout: 240 seconds]
Poorchop has joined #zig
cr1901_modern has quit [Ping timeout: 245 seconds]
cr1901_modern has joined #zig
<cr1901_modern>
Hmmm, a different/related question: If there a convention for how to write a build.zig for a library that depends on another library? lib.addPackage doesn't seem to be working for me
Guest91421 is now known as notzmv
<andrewrk>
in what way is it not working?
<cr1901_modern>
Given this build.zig I wrote, when I run "zig build" from the repo root, I get "cannot find zig-matrix".
<TheLemonMan>
great, time to check where the macros are getting lost then
cole-h has joined #zig
zenkuro has quit [Ping timeout: 246 seconds]
zenkuro has joined #zig
<TheLemonMan>
koakuma, sorry about the missing parameter, I forgot to git add the modified file before pushing
<TheLemonMan>
does it work once you add that back?
<TheLemonMan>
the missing macro problem can be debugged if you have built LLVM with debug symbols
<TheLemonMan>
because -detailed-preprocessing-record is being passed to clang but no detail is recorded
<ikskuh>
TheLemonMan, andrewrk: curious question: i have potential access to a (bad) MIPS machine (my old router) and a pretty strong PowerMAC. would those be of use for zig dev?
<TheLemonMan>
running every now and then the CI suite on the powermac would be helpful, I keep testing most of the non-x86 binaries using qemu
<ikskuh>
yeah that's what i thought
<ikskuh>
1.5 Gigs are enough? /o\
<TheLemonMan>
of ram?
<ikskuh>
yeah
<ikskuh>
it's not my machine, but belongs to a friend of mine
<ikskuh>
cool thing is we could still do a multiboot with some BSDs and linux :)
<TheLemonMan>
probably not :\ unless you chop the std test suite in smaller blocks
<ikskuh>
hmm
<ikskuh>
(wouldn't be a bad thing either, right?)
<TheLemonMan>
nope, that'd also be useful to overcome the lld bug when linking huuge mips binaries
<ikskuh>
and OOM in CI probably too?
<TheLemonMan>
the CI has something like 6G of ram, we're running at nearly max capacity
<TheLemonMan>
every now and then andrewrk prunes some tests to free some ram heh
<ikskuh>
what is also *a bit* annoying is that the first failing test crashes the test runner
drp has joined #zig
<koakuma>
I tried to build a debug version once, but the build process ate so much memory that half my processes died from the OOM-killer mess :(
<koakuma>
Ah, sadly my LLVM builds are in release mode
<plumm>
maybe invoking ub is a bad test harness issue
<koakuma>
Also, TheLemonMan, with added `.sparcv9` parameter, it builds but it's still segfaulting for me
<TheLemonMan>
segfaulting where?
<koakuma>
When running a program compiled with it
<koakuma>
The compiler correctly detected the CPU model as "&Target.sparc.cpu.niagara2", but the featureset is still empty
<koakuma>
I'll post the full show-builtin dump in the PR comments
<TheLemonMan>
ah good catch, I'm dumb and assumed the Feature api would pick that up
<TheLemonMan>
gimme a few mins and I'll amend that PR
<koakuma>
Ah okay
Akuli has joined #zig
ugla has joined #zig
<TheLemonMan>
koakuma, done!
<koakuma>
Okay, rebuilding!
<TheLemonMan>
have you checked #8618? the missing flushw was causing the stack walker to crash and burn while trying to print a stack trace
<koakuma>
Oh, will do after done with #8622
marijnfs has joined #zig
jmiven has quit [Quit: reboot]
jmiven has joined #zig
kiedtl has joined #zig
<kiedtl>
how would I coerce the expression '[_]f64{ v1, v2, v3 }' to []const f64? Shouldn't this be coerced automatically?
<Nypsie>
The address of an array will coerce to a slice, so: &[_]f64{v1, v2, v3}
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
jeang3nie has joined #zig
<kiedtl>
For the statement 'var foo = 0.0;', what does the error 'variable of type 'comptime_float' must be const or comptime' mean? That the variable has to be const in order to be assigned a float literal?
<ikskuh>
kiedtl: "0.0" has the type comptime_float
<ikskuh>
which is a type of undefined size (it's only usable at comptime)
<ikskuh>
and you cannot declare runtime variables of it
<ikskuh>
so yeah, you either need a concrete type (f64) or a "comptime var" (which behaves like a runtime constant)
<kiedtl>
Hm, so type annotations should be enough...?
<ikskuh>
yep
<ikskuh>
var foo: f64 = 0.0;
<kiedtl>
huh, thanks
<recalloc>
Hi, I'm wrapping a C library and I can't find any `c_float`. Should I use `f32` instead?
xackus_ has quit [Remote host closed the connection]
xackus_ has joined #zig
<marijnfs>
cool, a new zig-showtime
<marijnfs>
any suggestion whats the most interesting talk?
<kiedtl>
Does zig still support compiling *.zig into .o files suitable for linking by a C compiler with other .o files generated from C code? I'm trying to do that right now with `zig build-obj` but gcc complains about missing __zig_probe_something and the zig.o file not being compiled with PIE
<recalloc>
Looked at that before, searching for "float" shows no rsults
<recalloc>
I suppose I could add a feature request to the docs appending floats to the type list.
<andrewrk>
kiedtl, hmm ok so gcc's compiler-rt (aka libgcc) is missing __muloti4. I think that's actually a gcc bug. but can be worked around by additionally linking in the compiler-rt that zig provides
<recalloc>
I'm blind then, my bad. It wasn't in Chapter 4 in the C primitive types table which I looked at most, but the master documetnation with all primitive types have it
<kiedtl>
andrewrk: Hm. Thanks, I'll try that until I can rewrite the Makefile into a build.zig
<ikskuh>
andrewrk: how do i specify the entry point of a zig program precisely? *thinking*
<andrewrk>
ikskuh, export whatever entrypoint you want
<ikskuh>
we want to build a package that provides a "generic" entry point
<ikskuh>
and have the root file export "pub fn main()"
<ikskuh>
will that conflict with std somehow?
<ikskuh>
(on freestanding)
<andrewrk>
g-w1, no, too fancy, let the applications do that logic instead of putting it in std lib. IMO std.meta.eql is already pushing it
<g-w1>
ohh, but for testing you want good output, makes sense
<g-w1>
like not "this is false", but actually showing the values
<andrewrk>
ikskuh, you want a package that is an alternative to start.zig? that should already be possible, via `comptime { _ = @import("the-package"); }`
<andrewrk>
feel free to suggest modifications to this logic
<ikskuh>
if we find something, we'll report :)
<ikskuh>
oh and again: zig is awesome :D
<ikskuh>
comptime and type manipulation is brilliant
<ikskuh>
andrewrk: same question for the panic function. where does it get called? builtin.zig?
<andrewrk>
yes
<andrewrk>
so the use case is providing a default panic function, yes? that's something we might need to come up with an idea to solve
<ikskuh>
yeah
<andrewrk>
pub const panic = micro.panic;
<andrewrk>
this is the null hypothesis
<g-w1>
would that also reference micro? so you don't need comptime { _ = micro; }
<andrewrk>
yes it would
<ikskuh>
andrewrk: yeah
<ikskuh>
was just asking where that reference comes from
<andrewrk>
coincidentally, this is how stage1 internally creates a dependency on start.zig :)
<g-w1>
using the panic?
<andrewrk>
yes
<g-w1>
oh, cool
<andrewrk>
compilation kicks off with semantic analysis on `std.builtin.panic`
<ikskuh>
:D
ifreund1 has joined #zig
ifreund has quit [Ping timeout: 260 seconds]
<recalloc>
When wrapping a C function that writes to a *Type and returns a success code, is it idiomatic to wrap it into a fn(*Type) !void, or bring the Type out and make it a fn() !Type ?
<recalloc>
I see the stdlib has idioms like DataType.init(...) !DataType, which makes me wonder whether my wrapper should take the extra step going there.
<ikskuh>
recalloc: that depends on the semantics ;)
<recalloc>
Here's my specific case: a C function int SDL_GetResource(int index, SDLResource *resource) that returns 0 on success, <0 on error.
ur5us__ has quit [Ping timeout: 245 seconds]
l1x has quit [Quit: Connection closed for inactivity]
<plumm>
recalloc i just make a function that interprets the exit code as a zig error and wrap my calls with that
<recalloc>
I see. I'll probably do that for now, thakns!
Akuli has quit [Quit: Leaving]
maximum_yellow has joined #zig
jeang3nie has joined #zig
maximum_yellow is now known as op_4
notzmv has quit [Ping timeout: 260 seconds]
<op_4>
did ziglang.org drop linux-armv7a builds, or only for master?
SLWW has joined #zig
SLWW_ has quit [Ping timeout: 265 seconds]
mikdusan has joined #zig
<xackus_>
op_4 I don't think there were ever master armv7a builds on the website
<op_4>
xackus_: well that answers that, thanks
ifreund1 is now known as ifreund
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Bernstein has quit [Remote host closed the connection]
klltkr has joined #zig
klltkr has quit [Client Quit]
nvmd has quit [Quit: Later nerds.]
ifreund has quit [Quit: WeeChat 3.1]
ifreund has joined #zig
leon-p has quit [Quit: leaving]
xackus_ has quit [Read error: Connection reset by peer]