<mouseghost>
hi, is zig ever gonna have try without having to do assingnment?
<mouseghost>
assingment
<rifkik>
How do I exit my program in Zig?
<rifkik>
like how do I do it in code?
<mikdusan>
std.process.exit(0)
<rifkik>
thanks!
<mikdusan>
mouseghost: what do you mean?
<mouseghost>
mikdusan, well, currently i have to do _ = try fs.File.write(f, "hi"); now, so will there be this requirement for "_ =" part be removed? (unless i didnt get it at all then)
<mq32>
mouseghost, no, that will not be removed
<mouseghost>
thanks
<mouseghost>
aaalso
<mq32>
you are not allowed to discard any return values unless you do it explicitly by assigning it to _
<mikdusan>
try doesn't require `_ =`, it's that particular function. given a function returning `!void` and you don't have any assignment
<mouseghost>
is there some kind of sugar syntax thing to make something like f:write("hi") so that f becomes first argument or self?
<mouseghost>
oh
<mq32>
f.write("hi");
<mouseghost>
hmmm now i wonder why didnt it work when i tried it first time .w. maybe i misread the error back then. thanks!
<rifkik>
dumb question, but what's the equivalent of this. for (c = 0; c < 256; c += 1) ?
<mq32>
var c : usize = 0; while(c < 256) : (c += 1) { … }
<mouseghost>
mq32, shouldnt the comparison be different?
<tgschultz>
mq32: in zig 0.5.0 no, bmp lib is broken due to bad codegen I've yet to track down completely. In 0.4.0 it worked.
<mq32>
yeah i've built myself a netbpm library :D
<mq32>
have to write some tests for it though
<mouseghost>
pfff only real tests are the ones in prod
<mq32>
hey i even tested against 6 files! :D
<mouseghost>
ohno
<tgschultz>
its possible the old version of bmp and/or png would work if I updated them with syntax changes, but they were very quick and dirty.
<mouseghost>
cant you just use cinclude?
<mq32>
mouseghost, for what exactly?
<mouseghost>
mq32, emmm lib bmp?
<mouseghost>
or whatever is it?
<mouseghost>
it is*
<mq32>
haha
<tgschultz>
One could use C libraries yes, but these were pure-zig libs.
<tgschultz>
no dependencies
<mq32>
i think tgschultz hasn't written any C header for his zig libraries :D
<tgschultz>
My goal with zig is specifically never to have to use C again
<mq32>
tgschultz, yeah i'm trying the same here
<mq32>
but i think we have to wait some time until we can replace SDL2 with something pure
<mouseghost>
then what do you mean codegen
<mouseghost>
c to zig transport?
<mq32>
zig 0.4.0 to zig 0.5.0
<mouseghost>
ah
<tgschultz>
no, the codegen bug I refer to is in the way the compiler turns zig code into LLVM
<tgschultz>
something was broken there with 0.5.0, probably the result-location changes
<mikdusan>
tgschultz: llvm type not matching errors?
<tgschultz>
calls not matching function signatures
<tgschultz>
I think zig is incorrectly generating comptime-variadic functions, specifically when they involve packed structs with non-byte aligned members.
<tgschultz>
but I haven't created a minimal example yet
<mikdusan>
it should be acompiler error. but ends up codegen error. just fix the types to match and should work
<tgschultz>
I don't think this is the same, because the exact same code worked in 0.4.0. It's possible I made a mistake and the compiler didn't catch it and it just happened to work, I'm just skeptical.
<tgschultz>
Though, bmp does use a lot of comptime stuff. For example, you can just pass it a struct with r,g,b and a members and it will write pixels out in that format for you regardless of what they were in the bmp file. You can construct your decoder instance to only support certain formats, etc.
<tgschultz>
So it is totally possible there's something non-obviously wrong because of how that all fits together, I just have trouble believing it since it worked fine and passed the entire bmp suite worth of tests.
doublex has quit [Ping timeout: 240 seconds]
<tgschultz>
which include craziness like rgba16-1924
<tgschultz>
which is 16-bit RGB with 1 bit for red, 9 for green, 2 for blue and a 4 bit alpha channel
doublex has joined #zig
<mouseghost>
so i have this issue 'sys/socket.h' file not found
<mouseghost>
i do const c = @cImport(@cInclude("sys/socket.h"));
<mouseghost>
so how am i supposed to do this
<mq32>
do you link libc?
<mq32>
have you added the system include directory?
<mouseghost>
mq32, ive added -lc to the command, and i didnt add any system include dirs
<mouseghost>
lol it turns out i probably cant have sys/socket.h here on windows
<mq32>
mouseghost, yeah, that's correct
<mq32>
windows uses different libraries
<mouseghost>
i do have msys though
<mouseghost>
ok i found include dir
<mouseghost>
it still says it's failed c import but it threw other imports in
<mouseghost>
so im happy
lunamn_ has joined #zig
lunamn has quit [Ping timeout: 240 seconds]
<kahiru>
is there a "native" tcp library or should I just include sys/socket.h and friends and do things the same way as I would in C?
<mq32>
afaik there's a socket abstraction in std
mahmudov has joined #zig
diltsman has joined #zig
<diltsman>
Is there a way to dump struct layout? I'm wanting to make sure that I didn't mess up a C compatible struct.
<andrewrk>
diltsman, you can use comptime asserts and @byteOffset
porky11 has quit [Quit: Leaving]
<diltsman>
Clang has -fdump-record-layouts. Does Zig have something similar?
<andrewrk>
no
Akuli has joined #zig
kahiru has quit [Ping timeout: 265 seconds]
<traviss>
mq32: you stream on twitch? what is your channel name?
<mq32>
nah, i don't stream
<mq32>
i'm just watching streams :D
<traviss>
ah dang
<mq32>
my internet connection doesn't allow streaming
kahiru has joined #zig
mps has joined #zig
<mikdusan>
andrewrk: may i go ahead and merge #3368?
<andrewrk>
mikdusan, can you add that reduction as a behavior test first?
<mikdusan>
aye
<andrewrk>
the impl looks good
collector_of_pre has joined #zig
<collector_of_pre>
Hello, newbie to Zig here with a possibly misunderstanding...
<collector_of_pre>
If I have an invalid function, does `zig build-exe` (or some such command) not show the compilation error until I actually use that function in my code?
<collector_of_pre>
I would have imagined that `build`, `build-exe` or `run` (if not `test`) would have at least given a compilation error even if the function is not called from anywhere in the code?
<collector_of_pre>
I am using zig version `0.5.0+dca6e74f` by the way (from `master`)
<mq32>
collector_of_pre, zig is really lazy
<mq32>
it doesn't semantically analyze your functions until you use them
<collector_of_pre>
Oh. Is there any way to force that behaviour?
<collector_of_pre>
I mean to analyse it fully
<mq32>
no
<collector_of_pre>
:(
<mq32>
not that i know of
<mq32>
write tests!
<tgschultz>
That is something that has been brought up a few times as being a useful idea. I think there's an issue for it in the tracker, but it is low priority
<collector_of_pre>
Sure, tests are good, but during exploratory programming, it can be a real hassle
<collector_of_pre>
Hmmm...
<collector_of_pre>
Okay, at least I know now that it's expected behaviour... I was thinking I was missing something!
<collector_of_pre>
Thanks for the help, folks.
Barabas has joined #zig
<mps>
Hi, I'm trying to make zig package (apk) for Alpine Linux, but have issue in linking phase. is it ok to ask for help here about building it?
mahmudov has quit [Ping timeout: 240 seconds]
collector_of_pre has quit [Remote host closed the connection]
<fengb>
collector_of_pre: you can force it to compile with `_ = func` in a test block
mouseghost has quit [Quit: mew wew]
traviss has quit [Quit: Leaving]
traviss has joined #zig
<andrewrk>
mps, yes, what seems to be the problem?
mahmudov has joined #zig
<mps>
would you mind if I post my APKBUILD file for alpine and build log
<mps>
in short, it seems linker can't find libstdc++
<mps>
andrewrk: we are using llvm9 and batteries, and I'm trying to build zig 0.5.0
<andrewrk>
mps, I'm not sure what batteries is, but can you try putting libc++ on the linker line? look for target_link_libraries in CMakeLists.txt
<mps>
I have installed gcc, g++, musl-dev, llvm9-libs, clang-libs, clang-dev, llvm9-dev, lld-dev ... (I call it llvm batteries)
<mps>
I have to add that I'm not much versed with cmake
<andrewrk>
mps, hmm interesting, so these linker errors are coming from clang driver code that zig carries. this would suggest that there are alpine linux patches on the clang or llvm libraries being linked against which have made ABI incompatible changes
<andrewrk>
or it would suggest that you used a different compiler for the clang/llvm libraries than the one used for zig
<andrewrk>
uhh you're also using gcc for the c compiler but clang for the c++ compiler? that's not a good idea
<mps>
yes, patch which add add-musl-triples.patch
<andrewrk>
it also says -- Could NOT find CLANG (missing: CLANG_LIBRARIES) - Could NOT find LLD (missing: LLD_LIBRARIES)
<mps>
right
<andrewrk>
does your script run make even if cmake failed?
<andrewrk>
if cmake fails then it failed
<mps>
iiuc, cmake just make config, and make builds. or I'm wrong
<andrewrk>
please change your script to not blindly continue if cmake fails
<andrewrk>
this will be easier / more clear with the zig package manager, but you can fudge it with git sub modules or equivalent
<andrewrk>
it requires sort of hacking up the build system from make or whatever to zig build. but the benefit is then that you unlock full cross compilation
<mikdusan>
i still think there is a good delegation path to a lot of oo stuff
<tgschultz>
does that work the way I think it does? The VectorMixin generates a set of functions that Vec3 can call in method syntax?
<mikdusan>
yes
<tgschultz>
That potentially can be used to smooth out a lot of our interface stuff.
<tgschultz>
Though I'm really not feeling up to another go at interface reform just yet.
<tgschultz>
I didn't think we were going to let usingnamespace work that way. Personally I was actually against it due to my experience with Go's struct composition.
<mq32>
i'm quite happy that mixin logic now works
<mq32>
i have reduced my copy-paste count of a factor 3
<tgschultz>
I get where you're coming from, but having read a bunch of code with the struct definition spread between 5 or more different files I'm not super keen on it.
<mq32>
yeah, every feature can be used and misused
<tgschultz>
From my experience with Go, I feel like it will be `misused` much more often.
<mq32>
yeah but i don't think we can prevent this kind of "feature"
<mikdusan>
it could be. but isn't go's stuff embedding ?
<mq32>
as it's a side effect of "modules are just structs"
<tgschultz>
I was kinda hoping Andrew would lean the other way and make 'use' only work for cImport or something. But oh well, it's here now.
dingenskirchen has quit [Ping timeout: 250 seconds]
<mq32>
i think it's better that we can import some full modules into the global namespace
<mq32>
it may reduce readability in the same was as it can increase readability
<mikdusan>
this is really jumping the gun at part of #1717. with that you get this plus the new syntax.
<mikdusan>
*as part*.
<tgschultz>
I disagree there too. I like knowing which of the 3 dozen imports a given thing comes from
<mq32>
yeah, but this will lead to import names like V
<mq32>
because i'm too lazy to type a namespace every 4 characters
<tgschultz>
which is still better than nothing
<tgschultz>
I can at least look for `const V = @import("whatever");`
<fengb>
I’ve never seen that in any namespace heavy language
<mikdusan>
heh i'm opposite. i just import std and litter code with std.fs.File and std.math.big.Int ...
<fengb>
JS, Python, Elm, all keep sanely qualified names around
<mq32>
my focus is always some math-heavy stuff
<mq32>
and if i clobber `a + b * c` to `xq3d.math3d.Vec3.add(a, xq3d.math3d.Vec3.mul(b, c))`
<mq32>
it's much harder to grasp what actually happens
<mq32>
and this is an easy formula
<tgschultz>
and yet zig doesn't let you overload operators for a variety of good reasons
<mq32>
which drives me crazy already, but i can accept that
<mikdusan>
yeah i'm going to yield to math just seems to want it's own dsl'ish brevity
<mq32>
because now i have to switch on primitive type or "vector type"
<fengb>
Vector types should use @Vector and that supports operators :P
<mikdusan>
math is always a special case. almost every parser in the world does on thing, then does a crazy-ivan just to support math and operator precedence
<tgschultz>
math is alread its own DSL, we should just create a comptime function that turns formula written in tex into real code.
<mq32>
fengb, yeah but afaik vector types don't have readable subscripts like ".x"
<fengb>
mikdusan: except Lisp >_>
<mikdusan>
i see the >_> but i'm still going to say: why'd you go there? why?
<fengb>
Cause I’m the guy that has to be right, no matter how relevant the discussion
<mikdusan>
i agree
diltsman has quit [Read error: Connection reset by peer]
<_Vi>
How do I decode big endian integers and floats in Zig from `[]const u8`?
<mps>
I've built zig on alpine, zig0 shows options, help, etc. only have issue to build libuserland, but will left this for tomorrow
<mps>
thanks for help, and I hope we will have zig on alpine in a few days
<tgschultz>
_Vi: std.mem.readInt and its varients
<mikdusan>
_Vi: i have never used it but maybe std.mem.readVarInt
<mikdusan>
or you know what tgschultz said over a minute before me
<_Vi>
tgschultz, OK, there's readIntBig. How about floats?
<tgschultz>
specifically you probably want readIntSlice(Big|Little)
<tgschultz>
For floats read them as an int, then @bitCast to a float
<_Vi>
Shall such tricks be concentrated in a standard library, not in user code?
<tgschultz>
I dunno, up to andrew. It is not currently well defined what should be in std.
<tgschultz>
I wouldn't even call that a trick though. It's all just bits and how you interpret them.
<tgschultz>
Serialize/Deserialize do the exact same thing
<companion_cube>
int<->float is tricky enough it deserves its own function, imho
<tgschultz>
what's tricky about it? It's the same bits, it's just a matter of how to interpret them. This isn't like @floatToInt/@intToFloat. These bits are a float, we just use readInt to perform the endianess conversion.
<mq32>
btw, is there an option to usingnamespace on function/scope level?
<companion_cube>
tgschultz: you need to know about endianess and the precise representation of floats :/
<tgschultz>
no you don't. It is irrelevant how the float is represented because you aren't doing anything to the bits other than change the endianess.
<companion_cube>
sure. It's just error prone, is all.
<tgschultz>
how?
<companion_cube>
anyway serialization should always use a well defined format, not just dumping structures :s
<tgschultz>
Yeah, because everything understand XML
<tgschultz>
it's not like decades of computing accomplished anything just by putting bits on media or anything.
<companion_cube>
thanks for the strawman
<andrewrk>
mps, zig0 is not zig, please don't make that the alpine package binary
<companion_cube>
I was thinking CBOR, not XML…
<tgschultz>
it doesn't matter. there are currently hundreds of protocols and formats in common usage that are just structures on disk.
<tgschultz>
or wire
<companion_cube>
and currently there are a ton of vulnerabilities caused by that pattern, and the general use of C and unchecked formats
<mps>
andrewrk: ofc, no problem, I just wanted to report where I reached
<fengb>
We can’t fix existing formats
<tgschultz>
The vulnerabilities are not caused by the data, they're caused by bad interpretation of the data.
<tgschultz>
That isn't fixed by using a different format
<fengb>
If we don’t support them then that’s one less thing zig would support
<companion_cube>
and by the idea that "just read a struct" is acceptable
<companion_cube>
if you read data, you need a parser, that's my opinion.
<mps>
I read about lang few weeks ago and today found some time to look at it, looks really fine
<companion_cube>
(even if you're dealing with bad protocols)
<tgschultz>
Well, I disagree, strongly.
<companion_cube>
what good protocol based on "just dump structs" do you like?
<tgschultz>
You need to verify that the data you load from unknown sources is valid, that's all.
<tgschultz>
How about PNG? PNG is ok, and it's just structures on disk.
<andrewrk>
mps, good progress :) I will be happy to help with the rest later
<companion_cube>
seems to me like png is a well defined binary format for which you can write a parser?
<mps>
thanks again, and thanks for good language. your docker file helped me to understand it little more
<tgschultz>
...yeah? When you dump structures to disk in a defined way, that's serialization. That's what Serializer/Deserializer do.
<companion_cube>
I'd rather have a library that prints stuff to png for me. Serialization can be just "dump a struct on disk", but deserialization needs to be careful.
<companion_cube>
at some point you need to defined your structs in a way that exactly fits the format
<tgschultz>
I'm not sure what you're saying. Structs are, by definition, defined.
<companion_cube>
I thought zig could arrange their layout in any way it wanted?
<tgschultz>
It sure can, but serializer/deserializer always lays things out the way they are written unless you've overridden it.
<tgschultz>
but even just tagging structs as packed would fix the layout and work fine as long as you don't care about endianess
<companion_cube>
how do you serialize a slice of runtime known length?
<tgschultz>
Serializer/Deserializer don't, they leave any kind of pointer handling up to the caller to deal with and error if they don't.
<tgschultz>
But typically, you'd write length+data
<companion_cube>
ah, well, ok.
<companion_cube>
at this point you can also do a bit of comptime codegen for serializing to msgpack/cbor/… so it's interoperable
Ichorio has quit [Ping timeout: 246 seconds]
n_1-c_k has quit [Read error: Connection reset by peer]
n_1-c_k has joined #zig
<_Vi>
Is it coincidence that Github's programming language colours for Zig and for Rust are very similar?
<tgschultz>
I doubt it, we used to use Rust coloring before zig had its own
<rifkik>
Did somebody ping me?
<rifkik>
Sorry, unlike Discord, my IRC client limits the messages that I could see