<mikdusan>
andrewrk: in our ci/azure scripts are you sniping install artifacts of "rebuild LLVM with zig" from zig-bootstrap to create the tarballs `zig+llvm+lld+clang-TARGET-...tar.xz` ?
<mikdusan>
this is in researching suport for macos arm64 tarball (ci/release)
<mikdusan>
or basically following zig wiki "how to build llvm/clang/lld" from source?
<mikdusan>
oh i guess my question is lame, let me ask again
<mikdusan>
what steps are you taking to generate tarballs `zig+llvm+lld+clang-TARGET-...tar.xz` used in ci scripts
ur5us_ has joined #zig
kameliya[m] has quit [Ping timeout: 246 seconds]
kameliya[m] has joined #zig
earnestly has joined #zig
<marler8997>
I'm at 30 minutes into Andrew/Loris pair programming stream
<marler8997>
where the make is failing but the command is not
<marler8997>
It's got to be environment variables right? Is the makefile setting LD or something?
<andrewrk>
mikdusan, yep!
<andrewrk>
marler8997, <spoiler warning> we do eventually find the problem, a bug/missing feature of zig cc to support -MM
<marler8997>
ah
<mikdusan>
andrewrk: before I forget. -MM implies -E. and the -o overrides stdout behavior
bitmapper has quit [Quit: Connection closed for inactivity]
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kbd has joined #zig
zags has quit [Ping timeout: 260 seconds]
<andrewrk>
mikdusan, marler8997: -MM support turned out to be an easy fix. zig cc with jemalloc "just works" now
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
posixlix has joined #zig
<mikdusan>
upgrade to master, you should have much better luck with bigsur
Snektron has joined #zig
<qbit>
ooooo boy! :D
<brzg>
is there a way to specify that a function argument must be some variant of a generic, or do i just have to use anytype
<g-w1>
you can do fn f(comptime T: type, n: T)
<brzg>
i don't see how that would work, maybe my question was unclear: what i mean is, i want something like fn f(o: *std.io.Writer), but that actually works
<mikdusan>
but if you just want anykind of generic then use anytype, and let ducktyping do its job, or @typeInfo inspect and @compileError
<brzg>
i'll just duck anytype, thank
ifreund_ has joined #zig
sebonirc has quit [Quit: sebonirc]
tjammer[m] has joined #zig
bitonic has joined #zig
BitPuffin has joined #zig
<andrewrk>
qbit, I'd wait a week or two (or maybe two more for zig 0.8.0) because Jakub is starting to work on upstreaming his macho linker code
<qbit>
ok
<qbit>
ill settle for running it on my openbsd machine (since it was recently imported into ports \o/)
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
notzmv- has joined #zig
notzmv has quit [Ping timeout: 246 seconds]
notzmv- is now known as notzmv
<andrewrk>
nice
brzg has quit [Quit: leaving]
kbd has joined #zig
<mikdusan>
delving into cmake the last couple of weeks. the single-biggest issue with cmake is how it behaves very differently depending on its own installation path
<mikdusan>
so for example, on linux it's found in /usr/bin or some standard like that. just pkg add it and you're good to go
<mikdusan>
but on macos you get it by brew or macports or building it yourself
<mikdusan>
you can easily do the last option with nothing more than bone-stock macos and xcode installed. and as long as cmake is installed to a private "tree" (ie. no other libs mixed in) then it behaves like linux
<mikdusan>
however, when you use brew/macports, it gets installed in /usr/local or /opt/local . now here's the rub.
<mikdusan>
without doing ANYTHING to cmake that is special, if it comes from /usr/local/bin/cmake, it will search ../lib ../include automagically . same with /opt/local
<mikdusan>
(in macports case)
<mikdusan>
this fucks everything up. now depending on what brew/macports have installed, that's where those libraries are going to be found by cmake.
<mikdusan>
so when building llvm, where does it look for libxml2, or curses, or libedit, etc.
<mikdusan>
and then things get viral. because it finds stuff in the brew/macports trees.
<mikdusan>
so cmake can be told to stop doing that with one simple trick `-DCMAKE_FIND_USE_CMAKE_SYSTEM_PATH=OFF`
<mikdusan>
but then macos BigSur (and Catalina) throw us a curve ball. we still need to teach it about SDK. and the following need to be set:
<mikdusan>
CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, CMAKE_FRAMEWORK_PATH all pointing to the SDK-based paths. eg:
<mikdusan>
and once that is done, cmake actually works decently on macos to build llvm from a super simple path of /usr/bin:/bin:/usr/sbin:/bin and empty macos system + xcode.
<mikdusan>
this holds true for subprojects cmake, lld, lldb too
<mikdusan>
/end verbose dump
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<olabaz>
So I'm trying to call a C-function that modifies its argument. In the C function it takes in a pointer and I've written a Zig function that takes in a 2D zig array which I want to pass to the C function. How can I do this? I tried &A[0][0] but it says "cast discards const qualifier"
<ikskuh>
olabaz: this means that you have taken a pointer to immutable data
<ikskuh>
but the C function requires that you have mutable data
<olabaz>
ah ok I think I figured it out
<olabaz>
one other question, how can I pass an arbitrary size 2D array
<olabaz>
or a pointer to an arbitrary size 2D array
<ikskuh>
this depends on your use case
<ikskuh>
2D arrays are kinda tricky
<olabaz>
I don't know either dimension size at comptime
<ikskuh>
okay
<ikskuh>
so the only option is a linear 1D array
<ikskuh>
with dim_x, dim_y and stride
waleee-cl has joined #zig
<olabaz>
ikskuh: ok so I should just stick with 1d arrays?
<ikskuh>
yep
<ikskuh>
2D arrays are not a concept in unmanaged code
<ikskuh>
you have to partition linear memory by hand
<ikskuh>
which is usually done by using a column- or row-major layout
<ikskuh>
so {0,1,2,3} will be {{0,1},{2,3}} or {{0,2}{1,3}}
<olabaz>
yeah, so I have C code that handles that
<ikskuh>
same applies in Zig
<olabaz>
Ideally I would make a 2d array in zig and pass it to a function in C that decomposes it into a linear array
<olabaz>
It's nicer to index using [i][j] than [nrow * i + j]
<olabaz>
ok I think I have an idea though
<olabaz>
I'll just write my own struct
sord937 has quit [Quit: sord937]
dyeplexer has quit [Remote host closed the connection]
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
xackus_ has quit [Read error: Connection reset by peer]
xackus_ has joined #zig
notzmv has joined #zig
zags has quit [Ping timeout: 260 seconds]
craigo has joined #zig
maier has joined #zig
<olabaz>
Why am I getting this error: ./src/matrix.zig:41:15: error: expected 3 argument(s), found 4
<olabaz>
matNxM.set(0, 0, 1.0);
zags has joined #zig
<olabaz>
how am I passing 4 arguments
<olabaz>
oh it's self
<Nypsie>
The `matXnM` is passed as an argument
<olabaz>
I feel like the error should be clarified
<olabaz>
or maybe I'm just noob
<g-w1>
it should be clarified
<olabaz>
Is there a simple way to loop through a range e.g: for (int i = 0; i < N; i++)?
<ikskuh>
i should write a blog post about patterns
<ikskuh>
ifreund: this is also cool!
<ikskuh>
another thing i discovered for testing:
<andrewrk>
ifreund, defer and errdefer are lowered in a not ideal way in stage1; the expression is duplicated at every scope exit point
<andrewrk>
in self-hosted, each defer/errdefer expression exists only once, and control flow is directed through them
<andrewrk>
I think that is unrelated to your question; your code is optimal
<ikskuh>
https://bpa.st/F4EA this is a pattern that checks if you forgot to clone some data on copy
<tdeo>
wait, what does errdefer in a loop do? i was under the impression defer was scope-based not function-based
<ifreund>
tdeo: it is scope based, it only runs if the try within the loop fails
<ifreund>
and only the errdefer of the current iteration runs
<ifreund>
andrewrk: cool, that all makes sense, glad we've once again cleaned things up in stage2 :)
<olabaz>
so how can I pass an unknown length array to a function I am getting: ./src/matrix.zig:65:60: error: expected type '[*]f64', found '[6]f64'
<tdeo>
olabaz: use & on the parameter when you're calling it
midgard_ has joined #zig
midgard has quit [Ping timeout: 245 seconds]
<tdeo>
*[6]f64 will coerce to [*]f64
<andrewrk>
tdeo, the idea is to write zig code such that a line of code could be inserted pretty much anywhere, with a `try` in it, and have it participate correctly in error handling / resource management
<andrewrk>
that's why you sometimes see errdefer even with no "try" after it
<ikskuh>
tdeo: ifreund is smart. he uses the outer for loop to determine the inner for loops run length
<olabaz>
oh I see, I had a const qualifier and it messed everything up
<tdeo>
about the errdefer in a loop: i see, the behaviour makes sense but isn't immediately intuitive
<ikskuh>
btw, andrewrk: again much love for giving us zig. i had such a good coding session in the last 48h
<ikskuh>
ifreund: the problem with your errdefer pattern is that you need to replicate the errdefer behind the loop when *anything* after the loop can fail too
<ifreund>
true
<andrewrk>
you're gonna have to start thanking a lot more people - I'm down to only 54% of the total commit count now :D
<ifreund>
ikskuh: or extract it to a separate function
<ifreund>
(the loop I mean)
<ifreund>
or hope #5610 is accepted
<ikskuh>
andrewrk: true, but you're the spark and source of most core ideas. also the reason why zig is not cluttered with features
<TheLemonMan>
andrewrk, roger that, I'll send a PR if nobody beats me to it
<andrewrk>
thx for the mips issue btw
<ikskuh>
TheLemonMan: i was sceptical about the std.fmt refactoring first
<tdeo>
olabaz: this seems like it will not work with an allocator created at runtime, like an arena allocator. the allocator should not need to be known at comptime
<TheLemonMan>
np, I got commit access on the LLVM repo, the fixes for the other miscompilations are now in
<ikskuh>
but i used it today and it's a pretty cool pattern with std.fmt.fmtHexSliceUppercase
<andrewrk>
oh hell yeah, TheLemonMan with llvm commit access is incredible news for zig
<TheLemonMan>
ikskuh, glad you like it :) I prefer my hexdumps with plain {x}, the spacing helps so much
<ifreund>
\o/
<zags>
TheLemonMan: are they still using Subversion? :)
<olabaz>
tdeo: but I'm passing the allocator in as a variable
<tdeo>
olabaz: so you should probably have `pub fn Matrix(comptime T: type)` and `allocator: *Allocator` as a struct field
<tdeo>
you're passing it as a variable to the type itself
<TheLemonMan>
zags, thankfully it's git heh
<tdeo>
so only pointers that are known at compile time will work
<zags>
oh heh
<ikskuh>
TheLemonMan: doing a pr later which will be pretty useful for a lot of people :)
<olabaz>
ah ok
<TheLemonMan>
I also planned on moving Bi/BI into its separate Formatter, this way we finally get rid of all the weird formatters from the core fmt
<tdeo>
a common pattern with generic types in zig is to do `const Self = @This()` so you can use `Self` instead of `Matrix(T)` in the definition. nothing's wrong with typing it out, though
<ikskuh>
TheLemonMan: good idea
<ikskuh>
but we need to properly solve formatter alignment
<olabaz>
tdeo: where would I put that line, right at the beginning?
<ikskuh>
a hacky solution would be to first format without alignment into a counting writer, then use the result of this to align the output
<tdeo>
right before or after the struct fields i think
<TheLemonMan>
ikskuh, yeah, the core formatters should respect the options (too bad we can't force people's formatters to do so)
<TheLemonMan>
(nor to validate the fmt string, but that's a different story)
<ikskuh>
true
<TheLemonMan>
speaking of std.fmt, is anyone using the named parameters?
<ikskuh>
nope
<ikskuh>
:D
<ikskuh>
how is the syntax for them?
<ikskuh>
but even in current state, the formatting is so sweet
<andrewrk>
I think we have a discoverability problem for the named parameters
<TheLemonMan>
{[param_name]}, it's like positionals {[n]}
<tdeo>
wait, does it allow square brackets? because it worked without them for me
<TheLemonMan>
the restriction can be lifted, but then it'd be asymmetric wrt the other usage modes
<ikskuh>
ah, dang
<tdeo>
hm, not having brackets would be ambiguous. i think i didn't actually try and just assumed
<andrewrk>
since we are embracing the formatter pattern, do we perhaps want to use a different syntax than {} for formatting?
<andrewrk>
did C have it right all along with %?
<companion_cube>
print("«x» + «y»", …)
<ikskuh>
use / and \
<ikskuh>
print("/0\", .{ 10 });
<fengb>
lol
<ikskuh>
andrewrk: i think {} is pretty common
<ikskuh>
maybe we could use ticks: ``
<ikskuh>
print("Hello, `name`", .{ "andrew" });
<ikskuh>
.{ .name = "andrew" }
xyproto has left #zig ["WeeChat 2.9"]
<ifreund>
can't wait to update my stuff to zig 0.8.0 so I can use named format parameters in zig-wayland's scanner
<fengb>
We have named params now?
<g-w1>
ifreund: will river use the latest release of zig?
<ifreund>
g-w1: yes, I track the lastest relase with river to make contributing/packaging easier and reduce churn
<g-w1>
ok, yeah that makes sense
<tdeo>
my latest fmt issue was motivated by me experimenting with pure zig wayland again
<tdeo>
i was wondering whether having every object be a simple wrapper over a u32 would make sense, with the connection being passed through on every call
<olabaz>
what is the difference between [*] and []. Is [] a slice and [*] a pointer to an unkown number of items?
<tdeo>
olabaz: correct
<andrewrk>
correct
<olabaz>
then allocator.alloc() returns a slice?
<olabaz>
instead of a pointer?
<g-w1>
yes
<olabaz>
why
<g-w1>
to get a single object use allocator.create
<g-w1>
because it is safer to get a length
<andrewrk>
olabaz, a slice is more useful than a pointer, since you know the length. why would you want something less useful?
<olabaz>
in my matrix struct I have a field data: [*]T
<andrewrk>
the `ptr` field of a slice will give you that type
<g-w1>
as a workaround you can do .ptr on what it alloc
<olabaz>
ah ok
<olabaz>
I think I can just make data: []T since I will know the size when I fill it up
<ifreund>
tdeo: that sounds quite interesting, I really think a pure zig wayland library could be *way* better than libwayland
<ifreund>
unfortuneately I'm stuck with libwayland server-side at least cause there's no way I'm rewriting wlroots
<zags>
I see switching on "strings" have been a topic on discord a few times, would've been convenient right now. But I take it lowering to std.mem.eql doesn't fit the language? I didn't see anyone chime in when it was asked.
<ifreund>
zags: iirc someone implemented swtiching on strings and it wasn't any more optimal than the if-else chain with mem.eql()
<zags>
ifreund: yeah, but it's more convenient
<tdeo>
ifreund: i saw your issue comment on zig-wayland about protocol objects being generic over the version, i like that idea because it lets you bump the version and get compile errors where you should to change things
<tdeo>
i'm probably going to try that in mine
<companion_cube>
ifreund: it could be made more optimal by compilers
<g-w1>
zags: fengb does it in zigbot, so you can just use it if you want to not follow the conventions :)
<g-w1>
he hashes everything
<companion_cube>
with a trie, or any kind of decision tree really
<zags>
g-w1: yeah that works, but that's a trick :) I use string switching in a few languages, pretty neat
<ikskuh>
g-w1: "hashes"
<ikskuh>
afaik fengb just uses @bitCast to "hash" the string :D
<ifreund>
tdeo: cool, are you still working off the zwl repo? I'm curious to hear/see how it works out
<g-w1>
oh lmao
<zags>
hehe
<tdeo>
ifreund: i'll probably make a new one since i realized the name was already in use before my project
<tdeo>
hm, i wonder if we can guarantee single-field structs to have the same abi as the contained type
<Nypsie>
ifreund: Thanks for those zig fmt fixes. Makes fixing zls easier :P
<ifreund>
Nypsie: for sure, if you find any more bugs send them my way
<ifreund>
tdeo: I think distinct types that allow decls would be the cleaner solution there
<fengb>
It's a perfect has (assuming less than 16 characters and not all 0s)
<tdeo>
i was thinking about whether enum(inttype) or struct { id: inttype } is better if you don't have any abi restrictions (since the former can be used on in function parameters)
<fengb>
hash
<tdeo>
and the struct is probably better, but it would be nice to be able to use the struct over abi boundaries with an annotation like rust's #[repr(transparent)]
<tdeo>
but why do we need an annotation at all? guaranteeing that single-field structs are the same as their contents abi-wise shouldn't have any downsides, since that's already efficient, no?
<ifreund>
tdeo: what if the compiler wants to add extra fields in debug mode for some safety check
<tdeo>
that's true
<fengb>
zags: I prefer status quo. Right now you can pick your own algorithm using comptime matching. Go seems to use binary search, which can work but has major caveats
<fengb>
Whereas Zig switches mandates a switch table so something jumpable
<zags>
the compiler would work out a perfect hash yeah?
<ifreund>
tdeo: I think the enum is the way to go currently, but distinct types that allow decls would feel much less hacky
<fengb>
It's simpler to have a userland comptime implementation, especially since there's tradeoffs to every one of them
<tdeo>
yeah, i think that would be a nice addition. it would basically be the same as the enum but with no type restriction and fewer features
<tdeo>
i was considering just handling fixed to/from f64 conversion during serialization/deserialization
<tdeo>
(this isn't about the types anymore but i'm wondering about your opinion on that)
<ifreund>
I'm not a fan, it's planned for zig to have first class support for fixed point numbers
<zags>
fengb: i think a lot of the time, people end up doing if/else chains to match strings, so switching on strings could lower to that and be no less efficient than that at least, with other userland tricks when you need something else. Not very important, but was curious since it's been asked a few times.
<ifreund>
which would make using them everywhere feasiable/ergonomic while also being more performant without any downside
<tdeo>
thanks. yeah, language-level fixed-point numbers would be really nice
<fengb>
Would literals be fixed point then?
<ifreund>
hrm, I can't find the proposal... I am I confusing this with saturating arithmetic being accepted?
bitmapper has quit [Quit: Connection closed for inactivity]
<tdeo>
hmm, i think there's a clean way to merge both handle types and opaque{} together but it'd make the pointer part of the type. `handle(u32){}` would be a distinct u32, but `handle{}` would be equivalent to `*opaque{}`.
<tdeo>
i think that'd get rid of types of unknown size, which is probably good, but it'd make function signatures look different from c and therefore easy to mess up
<olabaz>
I'm interfacing with a C library and one of the functions wants the array size as an c_int but array.len gives me usize. How should I deal witht his?
<tdeo>
olabaz: depends on how you want to handle the case if the array is too big
<olabaz>
i don't want to handle it
<ifreund>
@intCast() then
<TheLemonMan>
:O
<olabaz>
lol
<ifreund>
which is illegal behavior if your array is longer than a c_int's max
bitmapper has joined #zig
<olabaz>
And how to deal with: error: expected type '[*c]const f64', found '*[]f64'
<TheLemonMan>
you're missing a .ptr on the slice
<tdeo>
you're passing a pointer to a slice, but you should pass the pointer *of* the slice, like `s.ptr`, not `&s`
<olabaz>
ah damn this is so confusing lol
<olabaz>
it's starting to make sense
<olabaz>
omg we compile and pass tests
<TheLemonMan>
woot woot
zags_ has joined #zig
Akuli has quit [Quit: Leaving]
zags has quit [Ping timeout: 276 seconds]
<olabaz>
is there a way to make sub tests e.g: Test("A") { Test("A1"); Test("A2");}
<g-w1>
why?
<olabaz>
so I can test a function with different types
<olabaz>
and loop over types
<tdeo>
you can do that in a single test
<tdeo>
i don't think there's more than that
<olabaz>
hmm ok
<tdeo>
maybe you can put a test in an anonymous struct, not sure how that'd get referenced though
<tdeo>
probably not recommended either way
<olabaz>
hmm, I guess I can't do a loop over types since I have comptime T
<tdeo>
you can iterate over types like `for ([_]type{u8, u32, u64})) |T| { ... }`
<tdeo>
that only works at comptime, of course
<g-w1>
i think you might need inline for
<olabaz>
g-w1: ah yeah adding inline worked
cole-h has quit [Ping timeout: 265 seconds]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
sebonirc has joined #zig
squeek502 has quit [Remote host closed the connection]
<zags_>
I'm looking for something that appends to an arraylist all the items from another arraylist, i.e Java-like "appendAll". Is there anything like that/would it be an acceptable PR?
<tdeo>
appendSlice?
<g-w1>
yeah, just do list.appendSlice(other.items)
<zags_>
oh damn, so nice, thanks guys
craigo has quit [Quit: Leaving]
zags_ is now known as zags
<olabaz>
I made a folder example and I'm trying to do @import("../src/matrix.zig") but it's giving me error: import of file outside package path: '../src/matrix.zig'
<olabaz>
compiling with: zig run examples/ex_gemm.zig --library c
tane has quit [Quit: Leaving]
<g-w1>
you need --main-pkg-path
<olabaz>
nice, how do you know this?
<g-w1>
zig run --help
<olabaz>
I'm trying to add a print function to my struct but it tells me: ./src/matrix.zig:44:27: error: expected type 'zb.src.matrix.Matrix(f64)', found '*const [2:0]u8'
<olabaz>
meh w/e I just removed it lol
notzmv has quit [Read error: Connection reset by peer]
<olabaz>
is there a way to get the zero of a type
<olabaz>
for example for int 0, f64 0.0, Complex(f64) = Complex.new(0.0, 0.0)