<andrewrk>
mikdusan, yeah I just spent the entire stream implementing the preprocessor more completely
ur5us has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 250 seconds]
Bekwnn has joined #zig
marijnfs has joined #zig
forgot-password has quit [Quit: leaving]
marijnfs_ has quit [Ping timeout: 264 seconds]
<pixelherodev>
ifreund, Are you using wlroots, or writing it all from scratch?
marijnfs has quit [Quit: Lost terminal]
ur5us has quit [Ping timeout: 260 seconds]
<ifreund>
pixelherodev: wlroots for sure
<ifreund>
no reason to reimplement all of that, and I doubt I could do a better job then those folks have
<pixelherodev>
Yeah, it's probably much easier to use wlroots in Zig than the Rust-Wayland peeps had it
<andrewrk>
on the stream today we successfully compiled LuaJIT natively with `zig cc`. it almost worked with -target aarch64-linux-musl but ran into lld: error: undefined symbol: __divtf3
<pixelherodev>
So just a single function missing in compiler-rt?
<andrewrk>
looks like it
return0e has joined #zig
daex_ has quit [Ping timeout: 240 seconds]
redj has joined #zig
return0e has quit [Ping timeout: 256 seconds]
<ifreund>
pixelherodev: well the wlroots-rs people attempted to create safe bindings, which is very hard to do with how lifetimes are managed in wayland
<ifreund>
if they had just used unsafe it wouldn't have been very hard
<fengb>
But unsafe is evilllllll
<mq32>
nice thing about comptime_int: it doesn't care about signedness
<mq32>
C/C++ is so picky about sizeof() and ssize_t
<ifreund>
i've used it for wayland clients, but there's nothing that can stand up to wlroots for compositors
<ifreund>
plus I wanted to learn zig :D
<Bekwnn>
does the std tend to return things in usize prolifically like the c++std does though?
<Bekwnn>
I haven't noticed it do that much. Meanwhile in C++ you use vector and WHOOPs into size_t land you go
<fengb>
std prefers usize when dealing with memory based indexing
<ifreund>
what's wrong with that? it's the accurate type to use
<Bekwnn>
I'd prefer it to be part of the template definition personally. Most C++ programs can be sped up by creating a vector class that uses int32_t internally for capacity and size
<Bekwnn>
uint*
daex has joined #zig
daex has quit [Ping timeout: 250 seconds]
<daurnimator>
ifreund: are you particularly familiar with wayland already?
<ifreund>
daurnimator: not an expert by any means, but this compositor isn't my first wayland project
daex has joined #zig
ifreund[m] has joined #zig
<andrewrk>
clang has an -O4 flag o.O
<Bekwnn>
I remember reading about how there is virtually 0 difference between O2 and O3
<pixelherodev>
That's not true
<pixelherodev>
-O2 is different from -O3
<pixelherodev>
But anything above -O3 on GCC is literally identical (e.g. -O4)
<pixelherodev>
Well, might be true on Clang
_Vi has quit [Ping timeout: 246 seconds]
daex has quit [Ping timeout: 250 seconds]
daex has joined #zig
daex has quit [Ping timeout: 264 seconds]
daex has joined #zig
<Bekwnn>
pixelherodev: I'm struggling to find it, but it wasn't so much about them _actually_ being the same as it was about the performance of several projects being pretty much identical under both. Can't find the article so *shrug*
<pixelherodev>
Ah
<pixelherodev>
That's probably pretty accurate
daex has quit [Ping timeout: 250 seconds]
daex has joined #zig
daex has quit [Ping timeout: 240 seconds]
slurpie has quit [Ping timeout: 250 seconds]
daex has joined #zig
<pltrz>
ifreund[m] are you me?
<pltrz>
hahaha jokes aside, I feel the exact same way about dwm and sway
<pltrz>
I like the master-slave model of dwm
<pltrz>
i was just thinking these days of starting a dwm-like under wlroots
<pltrz>
do you have a repo?
slurpie has joined #zig
daex has quit [Ping timeout: 256 seconds]
daex has joined #zig
jcharbon has joined #zig
dddddd has quit [Remote host closed the connection]
ky0ko has quit [Read error: Connection reset by peer]
return0e has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
daex has quit [Ping timeout: 256 seconds]
daex has joined #zig
return0xe has quit [Remote host closed the connection]
Bekwnn has quit [Remote host closed the connection]
daex has quit [Ping timeout: 250 seconds]
daex has joined #zig
daex has quit [Ping timeout: 264 seconds]
daex has joined #zig
slowtyper has quit [Quit: WeeChat 2.7.1]
slowtyper has joined #zig
watzon has joined #zig
<watzon>
Can I tell you how much I can not wait for zig to work well as a drop in C compiler?
<watzon>
I missed today's stream, gotta watch it later
slowtyper has quit [Client Quit]
slowtyper has joined #zig
frett27_ has joined #zig
slurpie has quit [Read error: Connection reset by peer]
return0e has quit []
return0e_ has joined #zig
return0e_ has quit [Client Quit]
return0e has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 250 seconds]
frett27_ has quit [Ping timeout: 256 seconds]
frett27_ has joined #zig
kenaryn has joined #zig
<kenaryn>
Hello computer people. Does anyone have tried NixOs AND VoidLinux and would accept to tell a few words about its both strengths and flaws? I wish to abandon Debian stable for a simpler and more efficient dependencies' system. Thank you
frett27_ has quit [Read error: Connection reset by peer]
frett27_ has joined #zig
<ifreund>
pltrz: repository is https://github.com/ifreund/zag its not currently in a state where I'm ready to accept patches, but I plan on doing the necessary organization and structuring today
<ifreund>
building on another machine might require some tweaks to the build.zig even
<ifreund>
kenaryn: NixOS is really great for managing multiple conflicting configs and sorta sandboxing development environments
<ifreund>
unless you
<ifreund>
unless you've bought into the systemd hate meme, I'd recommend arch over void for most use cases as it's just simpler/easier to work with
<kenaryn>
Thank you for your feed-back ifreund. mikdusan said nevertheless no more later than yesterday that ArchLinux was quite difficult to maintain it updated. Do you disagree?
<ifreund>
yeah, it's not hard at all imo. Also void is rolling release just like arch
<kenaryn>
I didn't know that last point.
<ifreund>
it's not like you need to update arch every day like some people do, you can easily go months without having issues
<ifreund>
as log as you don't do any partial upgrades of course
<ifreund>
also updating is not hard, far easier than updating a debian based system for example
<ifreund>
really you can't go wrong with nix, void, or arch though. Try em all and see which you like best imo
<kenaryn>
You're kind. In fact, it is intended mainly for web developpment and later for embedded programming. Does virtual environments would be sufficient or a OS-related sandboxing would be more appropriate?
<ifreund>
i personally just use arch + virtualenv for python and docker for a few other things. Hard to say if that'd be sufficient for your needs since I don't know exactly what they are
_Vi has joined #zig
<kenaryn>
Thank you, I think it's clear enough. By the way, do you know any advantage for virtualenv over venv?
<ifreund>
same think afaik
<kenaryn>
Allright, I will not talk about anything else than Zig for now. Andrew Kelley dislikes pretty much the signal/noise ratio's decrease. Thanks again =)
<ifreund>
no problem, sorry for the off topic talk andrew
Patrice_ has joined #zig
frett27_ has quit [Ping timeout: 264 seconds]
mahmudov has quit [Read error: Connection reset by peer]
mahmudov has joined #zig
dddddd has joined #zig
marijnfs has joined #zig
kenaryn has left #zig ["WeeChat 2.3"]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
daex has quit [Ping timeout: 264 seconds]
daex has joined #zig
slowtyper has quit [Ping timeout: 256 seconds]
<ifreund>
is it considered idiomatic to use @This() everywhere inside structs as one would do with `Self` in rust?
slowtyper has joined #zig
<andrewrk>
there's nothing wrong with doing that. Personally I prefer to use `const Self = @This();` and then refer to `Self`
<ifreund>
pretty neat that zig just lets you do stuff like that with types :D
<andrewrk>
argh this is throwing a monkey wrench into my efforts to prepare the CI for llvm 10: https://imgur.com/KHzO20U.png
<mq32>
oh no!
<andrewrk>
oh... that was the paris region. the amsterdamn region is all stocked up... I think I might have a guess as to why
Patrice_ has quit [Quit: Leaving]
frett27 has joined #zig
<frett27>
seems every body is launching a covid 19 following app :-)
<frett27>
there's a lot of work on this on github thoses days in EU
<mq32>
i'm coding c++ right now and i'm sooo missing a good autoformat and trailing-commas in function calls
<fengb>
Clang format doesn’t work that well?
<mq32>
nah, not with my coding style
<mq32>
for multi-line function calls i'm using zig style (even before zig)
<fengb>
Best part of zig fmt: your coding style doesn’t matter!
<mq32>
but looks like that's not the preferred c++ way of life :D
<fengb>
Yeah Zig matches my opinions better than most languages. But I was also happy to swallow my pride when working with Go
slowtyper has quit [Quit: WeeChat 2.7.1]
slowtyper has joined #zig
<scientes>
go also means you have to swallow your desire for manual memory management
<scientes>
and @fieldParentPtr()
<mq32>
btw, most malicios thing in clang-format: SortIncludes: false
<mikdusan>
btw, most malicious thing in c/c++: includes :P
<mq32>
mikdusan: yep
<mq32>
and compile time optimizaton based on include orders
waleee-cl has joined #zig
ifreund has joined #zig
TheLemonMan has joined #zig
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #zig
Akuli has joined #zig
hazeycode has joined #zig
<shakesoda>
mq32: anything that's not the preferred c++ way of life is probably for the better of society ;)
<mq32>
shakesoda: I throw "TType" at you
<mq32>
and FField
<fengb>
The non-preferred C++ way is probably worse than preferred :P
hazeycode has quit [Ping timeout: 240 seconds]
<companion_cube>
scientes: is that really a strong desire in you?
<companion_cube>
personnally Go seems like it'd kill me over my desire for sum types and generics
<fengb>
Oh I just meant that I absolutely despised the Go style but I stopped caring
<companion_cube>
that's still nice yeah.
<fengb>
Whereas Zig mostly matched my opinions already >_>
Ichorio has joined #zig
adamkowalski has joined #zig
<adamkowalski>
do we have a way to cast an anonymous list of T to a []const T?
<shakesoda>
adamkowalski: doesn't []T coerce to []const T? (just not the reverse)
<shakesoda>
or do you not have a []T to begin with
<adamkowalski>
well that's the thing, i'm trying to make my api accept any of those
<adamkowalski>
I have `session.run(foo)`
<adamkowalski>
where if foo is a single tensor then the output type should also be a single tensor
<adamkowalski>
if you pass me in a array of tensors where the length is known at runtime, I will return to you a dynamically allocated array of answers
<adamkowalski>
if you pass me a array of tensors with a the length known at compile time, I will return to you a statically allocated array of answers matchig the length
<adamkowalski>
if you pass an anonymous list of tensors then it should be treated as if it's a compile time known array
<adamkowalski>
does that example there make sense or should I explain it?
<shakesoda>
this has a surprising amount of try's, kind of odd to have so many failure cases in the api
<shakesoda>
anyway, i'm looking for how run is defined
<adamkowalski>
alright that function is a monster, so it might make sense for me to explain with some context first
<shakesoda>
you're already using @TypeOf like I'd have suggested
<shakesoda>
so I'm not sure I know where the problem is
<adamkowalski>
the library is called compute graph, and it's trying to be a competitor to tensorflow/pytorch
<adamkowalski>
but everything is written from scratch in zig
<adamkowalski>
it's designed to operate on what are called tensors
<adamkowalski>
so scalars, vectors, matrices, cubes
<adamkowalski>
however, it's a lazy API so when you say `add(&graph, x, y)` it doesn't actually add
<adamkowalski>
it just creates an operation on the graph saying eventually I want to add x and y
<adamkowalski>
operations on the graph are polymorphic and not known until runtime so you need to allocate space for them on the graph and hold essentially a vtable
<adamkowalski>
hence every operation requires a try
<adamkowalski>
then when you call session.run(foo) it will actually look at the graph, figure out what are the fewest nodes needed to compute the answer and finally do the work
<adamkowalski>
hence it needs to allocate again since we are working with matrices
<adamkowalski>
does that all make sense? i'm happy to answer any questions, and also try to defend the design I have
<adamkowalski>
I also encourage you to throw tomatoes or say how I can improve the API
<adamkowalski>
the problem is however, that when calling session.run often times you want to know the value of several tensors
<adamkowalski>
so if you can call session.run(a) to just get the value of a
<adamkowalski>
or you can call session.run(&[_]Tensor{a, b}) to get the answer of both a and b
<adamkowalski>
I want to simplify that syntax to session.run(.{a, b})
<adamkowalski>
but all 3 types of parameters should be accepted
<adamkowalski>
and the output type of session.run depends on the input type passed in
mattmurr has joined #zig
decentpenguin has quit [Quit: decentpenguin]
<shakesoda>
i feel like you could avoid most of the trying by preallocating some sufficient amount of memory for operations and set a flag for a completeness check slightly later or something, but at least it seems reasonable given the explanation
<shakesoda>
I see the problem though, and I'm not sure enough about the way anonymous lists are typed
<shakesoda>
maybe the best approach here is to look at one of the std apis that take in an anonymous list?
<adamkowalski>
shakesoda: the problem then would be that if you don't know how big the graph is up front you will get a random failure at a certain point
<adamkowalski>
the idea is that the allocations for graph construction don't matter because you do it once at the start of your application
<adamkowalski>
the portion that will be run frequently and needs to be fast is `session.run`
<adamkowalski>
that is how you will make predictions, and actually generate concrete values
<adamkowalski>
also, each operation can fail because I do shape and type inference
<adamkowalski>
for example if you add two their and their shapes don't match up and cannot be broadcasted together then it is an error as well
<adamkowalski>
then I can offer something that google and facebook cannot
<adamkowalski>
which is that if you have an invalid graph you can detect it at compile time
<adamkowalski>
once we get compile time allocators that is
<shakesoda>
it's just frustrating to have that much surface area for potential failures
<shakesoda>
imo
<adamkowalski>
and I'm open to how to clean it up
mahmudov has quit [Ping timeout: 264 seconds]
<adamkowalski>
I can get rid of the try for Graph.init and Session.init once we get return value copy elision
<adamkowalski>
I'm currently allocating the arena on the heap because other fields within the structure need to reference it
<adamkowalski>
but as far as errors when trying to add two tensors I"m not sure how you can ever garuantee those are going to work
<adamkowalski>
especially since most of the time the values are not known till runtime
<adamkowalski>
I think I got the anonymous list syntax working though!!!
<adamkowalski>
but my compile times are starting to increase A LOT with all this meta programming
<shakesoda>
the only way I can think of that'd avoid all the failure cases is if you had something like a prepare function that took in an operation list and types, then filled it out after, but i feel like that just causes new usability problems
<shakesoda>
it's probably viable, but i don't know if it'd be *better*
<fengb>
According to andrewrk, comptime is around 100x slower than it should be
<shakesoda>
and heh, compile times are a pretty strong reason i keep my metaprogramming minimal
<shakesoda>
in all langs, not just zig
<adamkowalski>
fengb: thank god, i'm gonna bank on that fact and keep on going with my current approach
<adamkowalski>
shakesoda: we don't have overloading so it's necessary in a lot of places it wouldn't otherwise be
<shakesoda>
overloading is a worse solution regardless
<adamkowalski>
i'm trying to keep it down when possible
<adamkowalski>
shakesoda: whats wrong with overloading
<adamkowalski>
I think it makes more sense to use overloading or a trait system then have methods on classes
<adamkowalski>
because then classes are not open to extension
<fengb>
I don't like extensible classes
<shakesoda>
overloading as a solution is something you end up with when you've already lost
<adamkowalski>
I've got further questions for both
<shakesoda>
like, it's always to address another failure, and adds ambiguity :\
<adamkowalski>
shakesoda: how would you approach the problem I was just solving
<adamkowalski>
I wanted to provide a uniform API for people so that it doens't matter what you are running you always call session.run
<adamkowalski>
otherwise I would need `runTensor`, `runTensors`, `runTensorsThatAreActuallyAnonymousLists`, `runTensorsThatAreInAStaticArray`
<adamkowalski>
fengb: my graph supports several different scalar types, f64, f32, f16, i64, etc
<adamkowalski>
lets say that instead of that you wanted a type that made sense for your domain such as dollars
<adamkowalski>
or watts
<adamkowalski>
you cannot extend my system with your new type because I rely on things such as + being defined
<adamkowalski>
so you could say okay, make a new function add which can you freely add to your type and then as long as you can x.add(y) you're golden
<fengb>
You're talking about polymorphism, which I'm fine with
<mikdusan>
adamkowalski: not sure if I understood array/slice/anon above, but here's a quick stab at a single-function allocating if runtime len:
<adamkowalski>
well but now your screwed because I cant extend i32 to support add
<shakesoda>
I don't think the run is where the design problem is happening - everything else is too abstract to begin with, and I have a feeling you could constrain the solution at some much earlier step to avoid a lot of troubles
<adamkowalski>
I can't overload so I can't just do a add(x, y) either
<shakesoda>
I'd have to go solve the whole thing myself to go further down that thought rabbit hole though.
<adamkowalski>
shakesoda: well like I said I'm open to any and all ideas
<adamkowalski>
but the fundamental problem I have
<adamkowalski>
is you need to suppor tensors
<shakesoda>
call it a gut feeling that there's an earlier point where you could constrain the types and simplify everything
<adamkowalski>
which are scalars such as 5
<adamkowalski>
vectors such as .{1, 2, 3}
<adamkowalski>
matricies such as .{.{1, 2,}, .{3, 4}}
<adamkowalski>
and then you can say add(graph, x, y)
<adamkowalski>
add does not care what you are dealing with, it will give you back the appropriate tensor
<adamkowalski>
and the other constraint I have which I have spend many weeks on
<adamkowalski>
you need to be able to take the derivative of any arbitrary mathematical expression
<adamkowalski>
so you need to know the entire computation graph so you can analyze it and understand how to differentiate through it
<adamkowalski>
thats the esesence of modern machine learning and gradient based optimization (what others call neural networks)
<adamkowalski>
and you need to be able to support differnt scalar types to be able to handle high or low precision so you can make the tradeoff between precision and performance
<adamkowalski>
all of that is already implemented, and there are tons of tests to show the different use cases. so if you look at any of those and think i'm doing something unidiomatic please let me know and I will gladly fix it
ur5us has joined #zig
<TheLemonMan>
pixelherodev, are you still seeing stack traces w/o file names and line numbers?
<jaredmm>
Where's a good example in std for OS conditional usages? std.net uses some os.SOCK_* values that aren't defined on all OSs.
<andrewrk>
jaredmm, perhaps lib/std/fs.zig
<andrewrk>
`std.Target.current` is a comptime value with all the information about the target
<andrewrk>
for example you can `switch(std.Target.current.os.tag)`
<andrewrk>
if that seems like a lot of boilerplate, it's because zig gives you *a lot* of information about the target
<pixelherodev>
TheLemonMan, I believe so
<pixelherodev>
I can pull trunk and try again if you want?
<TheLemonMan>
yep
slowtype1 has joined #zig
slowtyper has quit [Ping timeout: 250 seconds]
<pixelherodev>
TheLemonMan, got a bug with which to trigger a backtrace?
<pixelherodev>
`???:?:?: 0x7f96c28705a0 in ??? (???)`
<pixelherodev>
TheLemonMan, I'd say so
<kenaryn>
andrewrk what is the host's name you mentionned with ARM processors out of stock in Paris region? I think I'm being swindled with PlanetHoster.
<ifreund>
I assume there's no way to get zig fmt to wrap lines yet?
<TheLemonMan>
pixelherodev, danke
<andrewrk>
ifreund, that's not planned. what you can do is hint about what should be on separate lines in various ways, such as using a trailing comma in lists
<andrewrk>
zig fmt has no concept of line length
<mikdusan>
hmm I don't get that llvm10 error. maybe because gcc-9.3.0 ?
<andrewrk>
mikdusan, on ubuntu bionic with apt.llvm.org?
<mikdusan>
archlinux
<andrewrk>
it's a problem specifically with the packages in apt.llvm.org
<ifreund>
so basically you're saying i just need to use some variables to break stuff like this up? https://paste.rs/rQQ.png
<mikdusan>
ah ok nevermind me playing catchup :)
<ifreund>
not my fault the variable names are so log :D
<ifreund>
s/log/long/
<andrewrk>
ifreund, yes or you can put a trailing comma after the last @ptrCast parameter
<andrewrk>
ifreund, also, you should always use `const` instead of `var` unless you would get a compile error
<andrewrk>
said another way, always `const` unless you plan to mutate it
<ifreund>
really wish there was a compile warning that could be enabled to tell about unneeded `var`
<ifreund>
though I assume that suggestion's already been made
<pixelherodev>
TheLemonMan, does Zig hardcode the path to obtain debug info from? Could be because I have it in /usr/local
<andrewrk>
ifreund, and finally, you can use a normal pointer for c.wl_listener, rather than [*c]. just pick the correct pointer type, it'll wok
<andrewrk>
*work
<TheLemonMan>
pixelherodev, it does use relative paths from the build directory, but that doesn't explain why there's no line infos
<ifreund>
thanks for all the code review :D
<andrewrk>
np. I'm proud that it's easy to review zig code without really seeing any surrounding context :)
<ifreund>
it's fine to use the normal pointer even when I'm passsing a pointer to this function to the c library?
<ifreund>
(hence the callConv(.C)
<mikdusan>
Zig... putting code reviewers out of work™
<Barabas>
Would be nice to get some actual work done =P
<Barabas>
(Instead of spending my time reviewing stuff)
<andrewrk>
ifreund, yes. [*c] represents the type system missing information, much like *c_void. it's always better when you can use one of the zig pointer types that actually tells you wtf is going on in the memory
<ifreund>
sweet, good to know
<mq32>
andrewrk: wasn't there a proposal to forbid C pointers in normal code?
<andrewrk>
yeah still planned
<mq32>
👍
<Barabas>
What is 'normal' code?
<mq32>
non-autotranslated zig code
<mq32>
User-written zig code has no reason whatsoever to use C pointers
<Barabas>
ah ok, so you'd know when something is generated?
<ifreund>
wait so i've been using .*. everywhere for no reason? i'm too used to ->
<andrewrk>
I'm slower on the draw, need to get back below 1,000 so I can be fast again
<Barabas>
ifreund, yes life doesn't have to be so hard :D
<andrewrk>
ifreund, yeah, I mean the code's not wrong
<mq32>
oh no, 1003 issues! :D
<shakesoda>
you do indeed not need to use so much .*
<ifreund>
just not idiomatic :D, this is a great way to learn a language
<shakesoda>
andrewrk: I still have some places where I need to [*c] in ptrcasts (calling a c api) and don't know the way around it
<ifreund>
i got the straight up tranlation of the c code I was working off of done yesterday, today is splitting it up into a workable architecture and making it into more idiomatic zig
<mq32>
shakesoda: why that?
<andrewrk>
shakesoda, every one of these cases is either a bug in zig with the way type casting works, or ur doin it wrong
<pixelherodev>
TheLemonMan, I build it in a subdirectory
<pixelherodev>
Would that cause a problem?
<TheLemonMan>
pixelherodev, I've reproduced yer problem, gimme a few mins to find out what's wrong
<shakesoda>
mq32: because [*][*]T won't coerce to [*c][*c]T and I need the latter to do this interfacing
<mq32>
ah
<shakesoda>
so i had to ptrcast it
<mq32>
you can also just adjust your translate-c output to be correct instead :)
<andrewrk>
mq32, [*][*]T is supposed to coerce to [*c][*c]T
<andrewrk>
oops, shakesoda ^
<shakesoda>
if that's the case, it's a bug
<ifreund>
nice, knowing that trailing commas control zig fmt has totally fixed my line length complaint
<TheLemonMan>
the casting logic stops at the outermost cast
<Barabas>
andrewrk should it though? The [*c] pointers can be null, right and [*] can't be.
<shakesoda>
Barabas: as such it's safe to coerce *to* a *c
<shakesoda>
(which is the case here)
<mq32>
ifreund: trailing commas in function calls are just ♥️
<Barabas>
So if you give [*c][*c] to someone you might get it back filled with nulls, which will break your [*][*]
<shakesoda>
right
<Barabas>
I'm pretty sure I had a similar case and andrewrk told me it doesn't work :P
<andrewrk>
ifreund, you can also line break after `if (x)` and after any binary operator
<andrewrk>
Barabas, shakesoda: oh, yes actually I think you just need to put `?` in the correct place
<andrewrk>
the inner one
adamkowalski has quit [Ping timeout: 250 seconds]
<shakesoda>
that works
<ifreund>
sweet, orelse is a binary operator. That fixes the other issue I had
<andrewrk>
then you can additionally @ptrCast it to [*][*] but that obviously does not have safety checks, whereas normal coercions from [*c] have safety checks
<shakesoda>
ptrcast to [*]?[*] was able to coerce to [*c][*c]
<shakesoda>
it'd be nice if something like this case were documented, it's kind of hard to arrive at a reasonable solution for dealing with c apis that use **
<shakesoda>
i had to burn quite a while figuring out how to convince that to obey me
<mq32>
Now that i'm coding C++ again zig has awoken a deep fear of exceptions in me
<shakesoda>
-fno-exceptions
<shakesoda>
;)
<mq32>
yeah, but then error handling will be painful :D
<shakesoda>
not more painful than exceptions are.
<pixelherodev>
`-fno-exceptions -fno-rtti -Wall -Werror -Wextra -pedantic -O3` is my default CXXFLAGS set
<pixelherodev>
Remove `-O3` and it's the bare minimum I'll accept to work with C++
<shakesoda>
pixelherodev: same, but not O3
<pixelherodev>
Remove the `-fno-exceptions -fno-rtti` and it's my bare minimum for working with C
Barabas50 has quit [Remote host closed the connection]
Barabas53 has joined #zig
<Barabas53>
ok... whatever, I'm 53 now
adamkowalski has quit [Ping timeout: 256 seconds]
<andrewrk>
hmm the stack trace tests are quite brittle when start.zig is changed
Barabas has quit [Ping timeout: 240 seconds]
daex has quit [Ping timeout: 250 seconds]
<Barabas53>
> solution: never ever do post- or preincrement operators
<Barabas53>
Glad I don't =D
<Barabas53>
+= 1 is my friend. Easier to read as well.
<mq32>
i'm happy that andrew did not put them into zig
<mq32>
Barabas53: true dat
<Barabas53>
worst is function(argument, i++) (or ++i??) you never know what happens, or at least I don't.
<shakesoda>
even when you do it's bad code
<ifreund>
yeah I used to feel cool using them in, well, interesting ways. Now i've grown up a little and realised that I could read my own code
<mikdusan>
imagine naming a language successor after problematic syntax :)
<ifreund>
s/could/couldn't/
<Barabas53>
My favorite one is: while( i --> 0)
<shakesoda>
imagine making a language successor that's vastly worse than what it succeeds?
<andrewrk>
c++ ?
<Barabas53>
And keeps all the horrible things for compatibility, but isn't actually compatible. (As in C code doesn't compile cleanly as C++ ^^)
<shakesoda>
not to say there is nothing useful in c++, that isn't true
<shakesoda>
but it is almost always way, way worse than C in so very many respects
<andrewrk>
oh I'm late to the joke
<Barabas53>
lol
<mikdusan>
I think andrewrk evaluated before incrementing
<Barabas53>
I'm just very happy there's a sane language ;)
<shakesoda>
once zig gets #1717, my wishlist becomes simply "faster compiles" (although I still think the looping syntax is bizarre, and there's a good few ways to end up with confusing types)
<Barabas53>
You get used to it
<shakesoda>
well, I can be used to it and still think it's bizarre
<Barabas53>
=D
<mq32>
hehe
<andrewrk>
what's an example of ending up with a confusing type?
<Barabas53>
Though the extra thing on the while is a bit strange
<shakesoda>
constructs like while (cond) : (do some stuff) {} eternally feel weird even if I'm used to writing it, it is really self-inconsistent
<Barabas53>
Yes that one is a bit hmm... not sure.
<Barabas53>
But I do like that there's no for (i=0; i < N; i++) ^^
<Barabas53>
because it's not different from i=0 while(i<N) { i+=1 }
<redj>
are there any step by step instructions somewhere? I can't even get cmake to do it's thing right out of the box/clone. I get "does not appear to contain CMakeLists.txt" pointing to the root dir where there's no CMakeLists.txt
<Barabas53>
And once you need a bit more than the standard you get into discussions about whether while or for is better and you have wasted another half an hour =P
<shakesoda>
Barabas53: I'd like if my while didn't require leaking the loop counter out of the loop scope, where it's useless
<shakesoda>
andrewrk: I had to enlist help here to figure out how on earth to type a .{ "thing", "other thing", null }, and earlier there was the ** -> [*]?[*] situation, which is really hard to come up with
<shakesoda>
things of that nature
<shakesoda>
I think, generally, that is less of a language issue than something the compiler could be more helpful with
<Barabas53>
You can easily put an extra brace around the whole thing though, but I understand.
<shakesoda>
Barabas53: needing to add another level to contain that is pretty obnoxious :(
<shakesoda>
the way loops are is a nitpick though, it doesn't impede my getting anything done
<shakesoda>
they just feel inconsistent, and it'd be nice to not have the counter scope issue to begin with.
<andrewrk>
you're not alone with that feedback
<shakesoda>
slices can also be pretty confusing, although I think that's a much better situation with making arrays behave more consistently
<shakesoda>
there's a lot of situations where it's not obvious by writing it what you're going to end up with
<shakesoda>
to an extent this is just needing to get used to it, but i always feel like i'm hoping for the correct magic to happen
<Barabas53>
My main 'problem' with Zig is getting used to writing everything 'inline'. Especially with nested things that gets messy quickly. And on top of that the tests are in the same file...
<shakesoda>
that said, I very much like that slices exist, they're nice
<Barabas53>
Yes
<Barabas53>
Better than adding a span class 40 years later xD
mahmudov has quit [Ping timeout: 250 seconds]
<Barabas53>
They're one of the most basic things, so it's great they're build into the language imho
<shakesoda>
I've described zig on several occasions as "like C that learned something from the last several decades"
<Barabas53>
Plus I'm very happy there aren't any constructors, destructors or private members which you can't get to
<shakesoda>
yeah, not having hidden stuff happen behind your back is one of the things that pulled me in to begin with
<Barabas53>
And the error handling is great
<Barabas53>
The only thing I'm not sure about is extending existing 'classes'. If you need to add this one method, you can no longer use `thing.my_method()` but have to type `MyExtension.my_method(thing)`
<shakesoda>
and you'll always know exactly where it is.
Akuli has quit [Quit: Leaving]
<shakesoda>
this is a feature, heh
<TheLemonMan>
pixelherodev, what compiler did you use to compile that binary?
<shakesoda>
it's also not something I run into the way I design programs, so maybe I'm missing the point.
<Barabas53>
It's mostly a problem when you use libraries. When it's all your code, you can just change it where you need to.
<Barabas53>
I also don't run into it that quickly, but it's something I've been wondering about.
<shakesoda>
the same statement applies though, I don't design things with the idea of extending classes
<shakesoda>
(similarly, inheritance is banned in my c++ codebases, it is simply not how things are designed)
adamkowalski has joined #zig
<fengb>
I’ve found extension methods to be far more annoying than they are useful
<Barabas53>
Well, I've had it happen a few times (twice?) that I wished there was some method on std.ArrayList which wasn't there.
<fengb>
Yeah and imagine if every library decided that
<fengb>
Now you have 2 dozen new methods on ArrayList that you don’t know where it comes from
<shakesoda>
i'm quite happy with just writing a regular function and calling do_the_thing(&list, ...)
<shakesoda>
never any mysteries, dirt simple
<Barabas53>
Sure
<shakesoda>
simplicity is a virtue
<shakesoda>
an idea which i think brings most people around here anyways, heh
<Barabas53>
But then you want it to work for more than one type
<Barabas53>
And just to be clear. I'm not saying it's abd to write a separate method.
mahmudov has joined #zig
<shakesoda>
one should generally prefer concrete over abstract implementations for simplicity, but you can totally substitute in a var
<shakesoda>
so, not too different
adamkowalski has quit [Ping timeout: 256 seconds]
<shakesoda>
it's a tangent, but interestingly, I've found that I use things like ArrayList quite a lot less in zig than I end up using vectors and the like in C++
<ifreund>
what do you use instead? or are you just using fewer containers in general?
<shakesoda>
it's been appropriate in more cases to just use slices and poke the allocator myself
<shakesoda>
ifreund: yeah, fewer in general, as the basic tools are quite good
<shakesoda>
I feel like in that case there's not really much of a benefit in the struct wrapping
<shakesoda>
it lets you call with your ., but you might as well just call ensureSize(list, size) by itself if you've got the function in scope
<Barabas53>
Yes, but the one advantage the `list.method()` has is that it already knows the type
<Barabas53>
while `ensureSize(list, size)` doesn't, so you have to do `ArrayListExtension(u32).ensureSize(list, size)` which is a bit longer than I'd like.
<Barabas53>
I also have no suggestion how to make it better though :P
<Barabas53>
In C++ I would use function overloading, but after you've done that three times you start to regret it as well ^^
<shakesoda>
I was thinking just typing the list argument with var and letting it be loose, compiler will scream at you if it won't work
<Barabas53>
Yeah might also work.
<shakesoda>
i've got a few functions on hand that work that way, it's been fine and not overly verbose or anything either
<Barabas53>
Yeah, well it's really my only complaint, so no biggy.
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
Barabas53 has quit [Ping timeout: 240 seconds]
<pixelherodev>
GCC 9.2-r4 I think
<ifreund>
why do we need to label a block to break from it? Shouldn't a break without a label always function on the innermost block?
<mq32>
ifreund: this would result in a lot of confusion
<mq32>
while(some) { if(some.other) { break; } }
<mq32>
your idea would mean that break is now breaking the if-block, not the while block
<ifreund>
ok I see how that could cause some problems, (though arguable only because people are used to what break does in C)
<mq32>
nah, break is fine as it is
<mq32>
it's good to see what blocks can break by start
<mq32>
and to have a separate syntax for value return
<ifreund>
Does make simple cases like this a little more verbose than I'd like, though I can live with ithttps://paste.rs/KEH.png
<mq32>
i would not do that
<mq32>
i bet that there's a hidden resource leak
<mq32>
what do you intialize the other fields with?
<ifreund>
hmm?
<mq32>
is .renderer owning or not?
<mq32>
and are other fields in your struct owning something?
<ifreund>
the c lib allocates the memory
<mq32>
so you don't have to call free() or clib_free() or whatever?
<ifreund>
i do
<fengb>
If 2nd statement fails, the 1st statement might be leaking
<ifreund>
thanks fengb
<mq32>
yep, that's what was my thought as well
<ifreund>
yeah I think I'll restructure this a little
<mq32>
also if *any* statement here fails (when initializing other fields), you are leaking them as well
<mq32>
just initialize the struct field-by-field
<fengb>
Might be prudent to add errdefer, but it won’t work inside of a separate block :/
<ifreund>
so maybe i should just make the struct undefined then init the fields one by one
<fengb>
Sometimes I wish I could add a defer to the parent block