<ryuukk_>
prior to zig, i tested rust, it lasted 5 minutes lol, so far zig feels much nicer, a bit rough to start due to the difference with C++/D, but i like the simplicity, if i were to rank the getting started experience, D would be #1, next is zig, and last one C++, rust is disqualified
<ryuukk_>
the build.zig is a little bit confusing
<g-w1>
I like rust a lot, but also zig. I had never done heap allocation before so it was cool to learn it.
<ryuukk_>
well i'm still beginner, i can only judge the getting started experience for now
ryuukk__ has joined #zig
ryuukk_ has quit [Read error: Connection reset by peer]
<andrewrk>
rust is 10 years old, D is 18 years old, zig is 5
ur5us has quit [Ping timeout: 260 seconds]
lanodan has quit [Ping timeout: 272 seconds]
<nikki93>
zig's time-to-lsp-working on all platforms i try (linux, macos and win) feels like the quickest of any lang i've tried so far
<nikki93>
nim is also p good while being not as mature as the others
<nikki93>
(as /most/ others -- maturity maybe comparable maybe slightly more than zig)
<g-w1>
I find that zls only works half the time for me. Is this the case for you?
<nikki93>
oh yeah it doesn't cover a lot of based. but i like that it just clearly doesn't work when it doesn't. rust's has just literally hung my editor before lol
<nikki93>
*lot of bases
<nikki93>
nimlsp has seemed good
ur5us has joined #zig
msingle has quit [Ping timeout: 240 seconds]
lanodan has joined #zig
<ryuukk__>
exe.linkSystemLibrary("../libs/glfw3"); i try to link the glfw lib, but it doesn't seems to work: error: unable to generate DLL import .lib file: Unexpected
<ryuukk__>
that still doesn't anwser the why it couldn't be 2 different function
<torque>
you could write your own simple wrapper around it if it is a real sticking point for you
<torque>
like "log" and "logFmt" or something
<ryuukk__>
it's not just about me, it's the confusion it adds, if you want to print a message, you don't want to print a message with arguments
<torque>
sure, but you have to tell it to explicitly print a message with no arguments
<torque>
it sounds like your expectations are geared around languages with either varargs or function overloading
<torque>
though I would guess the bigger problem here is the very rough state of the documentation
<ryuukk__>
no, that's your assumption, the point is to distinguish between a call that wants to print a message and a call that wants to print a formated message
<torque>
why should that distinction be made?
<ryuukk__>
because the empty anonymous is passed when you want to print a message
<ryuukk__>
struct *
<lunamn>
doesn't that already exist in the writer interface? write() vs print(), except I don't think write() is exposed as something like std.debug.write
<torque>
yes, I would say the interface is optimized around the assumption that you might want to expand your logging to include formatted data with as little change as possible
<torque>
which seems like a reasonable choice to me
<ryuukk__>
if it ask for a struct, the function is meant to pass a formated message, not a plain message
<torque>
that's not true, though
<ryuukk__>
why pass a struct then?
<torque>
the tuple being passed in is the list of variabls to format
<torque>
if you wanted to format something you would have to call std.log.info("my data: {} {}", .{data1, data2})
<ryuukk__>
but i want to pass a message, not a formated message
<torque>
so if you wanted to print an empty struct/tuple you would have to call std.log.info("empty: {}", .{.{}})
<ryuukk__>
why do i need to pass a message with an empty struct?
<torque>
yes, by providing nothing to format inside the list of things to format, you are explicitly telling it there is nothing to format
<ryuukk__>
than the function should be called info_formated()
<torque>
you are disagreeing with the api designer at this point, which is a qualitative argument rather than a quantitative one
<torque>
I think it's simpler to have one API call that is consistent between messages without formatting and with
<ryuukk__>
i am trying to clear confusion, not disagreeing with the api designer
<torque>
I do not understand what the confusion is
<ryuukk__>
the confusion, is why do i need to pass an empty struct if i just want to print a message
<ryuukk__>
i understand the struct is meant to format the message, but i just want to print a message, not a formated one
<torque>
the answer is that there is no syntactic sugar to hide the empty tuple at the call site and the API designer has elected not to draw a distinction between messages that format variables and those that do not
<ryuukk__>
i don't want to hide the empty struct
<torque>
which is why I am saying that you are arguing with the API. I think you have a good understand of how it works, but not why the API is designed the way it is
<ryuukk__>
i want to pass just a message
<ryuukk__>
hiding the struct = hiding the intent of the function, that's not what i'm asking
<torque>
the variable formatting is managed at compile time and not runtime, which may help you to understand why the API is the way it is
<torque>
there is no runtime penalty for not making a distinction between formatting and and not formatting
<ryuukk__>
i understand that, you still miss my point, i expect info to take my message and print it
<torque>
which it does when called std.log.info("my message", .{})
<ryuukk__>
no, it asks for a message and a struct, not just a message
<ryuukk__>
std.log.info, asks you to format a message
<torque>
I will say one last time: you are arguing about the API design and I cannot help you there. If you want add more functions to the API you are welcome to make a proposal to do so
<torque>
but this conversation isn't going anywhere
<ryuukk__>
that is the point!!
<ryuukk__>
discussion about a confusion that lead to solution
<ryuukk__>
my proposal: infof(string, struct) info(string)
<ryuukk__>
i am new i thought it'd first discuss about it with advanced users first to see why i have the confusion and what are the solutions before trying to make changes
<torque>
Well, I don't think such a proposal would be likely to be accepted given the history around the subject
<torque>
though I am certainly not an expert, and it doesn't hurt to make one
<ryuukk__>
well if it is a common recurence then maybe there is a real problem
<torque>
but as I tried to explain my perspective on why the API design makes sense and you consistently disagreed, I have no other suggestions for you
<ryuukk__>
i didn't disagree, i just tried to clear confusions
<torque>
you were not able to express why you are confused
<ryuukk__>
you didn't want to understand :)
<torque>
as far as I can tell, your "confusion" came down to "why are there not two separately named functions to perform these things" and my answer was "the API is not designed to treat those two things as distinct special cases"
<torque>
you did not particularly explain why you think they should be treated separately
<ryuukk__>
no, my confusion was why do i need to pass an empty struct if i want to just print a message
<torque>
good luck
<ryuukk__>
you don't want to understand, instead you extrapolate what would be my confusion
<ryuukk__>
look, what i said initially: [4:08:53 am] <ryuukk__> something random, why do i need to add the .{} here: std.log.info("on_init", .{}); ?
ur5us has quit [Ping timeout: 240 seconds]
<andrewrk>
no need to defend yourself. everybody respects you here
<andrewrk>
you asked me about changing .{} syntax? that's stable at this point, not planned to change
<ryuukk__>
no, i was suggesting renaming that function, since it requests for a formated message (msg + struct), and use the original name for passing just a plain message, but i hear the reasoning behind it, still it's confusing for me, maybe because i'm used to the info/infof split with other language
msingle has quit [Ping timeout: 265 seconds]
ur5us has joined #zig
radgeRayden_ has quit [Remote host closed the connection]
jjsullivan1 has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
OpenSpace has quit [Ping timeout: 260 seconds]
OpenSpace has joined #zig
earnestly has quit [Ping timeout: 264 seconds]
ur5us has quit [Ping timeout: 260 seconds]
<andrewrk>
llvm11 branch merged into master
keegans has quit [Ping timeout: 272 seconds]
keegans has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
ugghh ci broken because llvm-config on macos has a dynamic dependinc on libstdc++ that is somehow broken on the CI server
<andrewrk>
this is such an unnecessary problem yet it's a showstopper
redj has quit [Ping timeout: 272 seconds]
redj has joined #zig
kristoff_it has joined #zig
osa1 has joined #zig
<andrewrk>
wait a minute... there's a really obvious solution to this
PC98017 has joined #zig
cole-h has quit [Ping timeout: 264 seconds]
frett27 has quit [Ping timeout: 256 seconds]
ifreund has quit [Ping timeout: 258 seconds]
<andrewrk>
I'm updating freebsd and macos CI to take advantage of zig-bootstrap instead of the current system. This will have 2 benefits:
<andrewrk>
(1) it will work instead of not working
<andrewrk>
I'm being cheeky, what I mean is that we won't be at the mercy of gcc's libstdc++ being unreliable which is making the CI fail right now
<andrewrk>
(2) freebsd and macos tarballs will have a dynamic link against the system libc instead of incorrectly static linking the system libc
FireFox317 has joined #zig
<andrewrk>
that was always the goal, but without zig cc it wasn't possible to get the desired result
FireFox317 has quit [Remote host closed the connection]
<ikskuh>
advantage (1) sounds like a game changer :D
<andrewrk>
maybe the gcc team will take inspiration from (1) and apply it to their own software too ;)
ur5us has joined #zig
<ikskuh>
let's hope so
frett27 has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
wilsonk has left #zig [#zig]
ifreund has joined #zig
captainhorst has joined #zig
frett27 has quit [Ping timeout: 272 seconds]
ur5us has quit [Ping timeout: 260 seconds]
earnestly has joined #zig
ur5us has joined #zig
omglasers2 has joined #zig
decentpenguin has quit [Read error: Connection reset by peer]
<ikskuh>
daurnimator, you either need a new password or more sleep
<daurnimator>
ikskuh: it's a one-time-code from bumping my yubikey
supercoven has joined #zig
decentpenguin has joined #zig
Guest43791 has joined #zig
Guest43791 has left #zig [#zig]
<ifreund>
so zig's bool is a c_int when used in a extern declaration right?
<ifreund>
or no, I guess it's probably _Bool?
<earnestly>
I'd hope so...
<earnestly>
Considering the use of an int to store a bool has already been used in the underhanded c contest to deliberately construct an AES encryption that can be transparently toggled
<earnestly>
By storing additional information in the space available to the type
<ifreund>
i think zig's bool has to be _Bool, we have c_int already for the other option
frett27 has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
frett27 has quit [Ping timeout: 260 seconds]
mmohammadi981266 has joined #zig
mmohammadi981266 has quit [Client Quit]
marnix has quit [Ping timeout: 260 seconds]
marnix has joined #zig
mmohammadi981266 has joined #zig
mmohammadi981266 has quit [Client Quit]
captainhorst has quit [Quit: captainhorst]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
r0bby has quit [Ping timeout: 260 seconds]
kwilczynski has quit [Ping timeout: 260 seconds]
r0bby has joined #zig
kwilczynski has joined #zig
xackus has joined #zig
layneson has joined #zig
aruniiird has joined #zig
<ryuukk__>
is it possible to have a generic struct and not a function that return anonymous generic struct?
<ifreund>
the struct isn't anonymous, you have a name for it
<ryuukk__>
to me using function is adding 2nd way to do the same thing..
<ryuukk__>
i don't want anonymous struct
<ifreund>
the struct returned by e.g. ArrayList(T) is not anonymous, it has type ArrayList(T)
<ryuukk__>
why is it different for struct?
<ifreund>
e.g. ArrayList(u8) is one possible type
<ryuukk__>
this is wha is weird
<ifreund>
all that zig does is let you use types as first class values as comptime
mmohammadi981266 has quit [Quit: I quit (╯°□°）╯︵ ┻━┻]
<ifreund>
s/as/at/
<ryuukk__>
i'm not sure i like this, it doesnt make sense
<ryuukk__>
this is uneeded complexity
mmohammadi981266 has joined #zig
<ryuukk__>
everylanguage it's this way MyStruct<T> { data: T} that's it
<g-w1>
its more simple in zig
<ryuukk__>
compiler genrate what ever it needs to
<g-w1>
no need for macros
<ryuukk__>
well, not simple for me
<ryuukk__>
user become the macro generator
<ryuukk__>
pub fn ArrayList(comptime T: type) type
<ryuukk__>
this is a function, not a struct
<ryuukk__>
it as fn
<g-w1>
in zig functions can return structs
<g-w1>
all structs are anynomus
<ryuukk__>
saying it is a struct is mistleading people and add friction
<layneson>
std.ArrayList itself is a function, yes. However, as soon as you evaluate it, it becomes a struct type. std.ArrayList(u8) __is__ a struct type
<ryuukk__>
why not use same syntax for creating a normal struct?
<ryuukk__>
this is asking for confusion
<ifreund>
no, this is what you get when you remove everthing unecessary
<ifreund>
this requires no new syntax or semantic
<ifreund>
this is the natural outcome of comptime
<ryuukk__>
even go is same syntax for creating struct and generic struct
<ifreund>
there's no such thing as a "generic struct" in zig
<ryuukk__>
well if the goal is to not create language feature i sould just write asm
Stephie has quit [Quit: Fuck this shit, I'm out!]
<ifreund>
you merely have the ability to create your own types at comptime
<g-w1>
the goal of zig is not to be the same as other languages
<g-w1>
then there would be no point to it
<ryuukk__>
> there's no such thing as a "generic struct" in zig
<ryuukk__>
that is an anwser i can understand
<ifreund>
there is of course an equivalent pattern solving the same problem as generic structs without introducing new syntax or semantics
<ryuukk__>
not being the same as other language shouldn't be a goal
<ifreund>
as demonstrated by std.ArrayList
<ryuukk__>
i want solve problems, not be different than others
<ifreund>
being different isn't a goal
<ifreund>
being the same isn't either
<ifreund>
I'm not really sure what you're issue with how zig does this is, where do you find it limiting?
<ifreund>
*your
<ryuukk__>
it's a different way to do the same, so far language taught me to write struct this way: const MyStruct = struct{}
<ryuukk__>
to make it generic now i need learn how to do it an other way
<ryuukk__>
this is working against me
<ryuukk__>
instead of empowering me to write less and be more effective
<ryuukk__>
i'd rather what const ArrayListI32 = struct {}♥
<ryuukk__>
write*
<ifreund>
well, you aren't writing a struct, you're writing a function that returns a type
<ifreund>
of course that's different from writing a struct
<ifreund>
but it's not complicated either
<ryuukk__>
maybe not for you, but for me it is
<ryuukk__>
jungling between 2 syntax to do the same thing
<fengb>
I don’t think zig if for you
<ifreund>
there aren't 2 syntaxes
<ryuukk__>
fengb: that's what i start to realize
<ryuukk__>
wich is sad because otherwise i like the language
<ryuukk__>
also saying "i don't think zig is for you" is bad..
<ryuukk__>
what is new syntax in language in development?
<ifreund>
a major goal of zig is to be as simple and consistent as possible
<ifreund>
uneeded new syntax goes against that goal
<ryuukk__>
so i stand correct, having 2 different way to achieve the same thing goes against that goal
<ryuukk__>
you said it, both are anonymous struct
<g-w1>
everything is a value. there are no generics in syntax constructs
<ryuukk__>
(im not language designer, so i might see things differently than you)
<dutchie>
yeah, the key insight is that types are first-class values
<ifreund>
and zig doesn't need anything more than that to have "generics"
<ifreund>
having generics is just a byproduct of comptime
<dutchie>
this immediately made sense to me because i went to a type theory class once
<dutchie>
"oh it's just dependent types if you squint right"
<ifreund>
yep
<ifreund>
a function taking a type and returning another based on that argument is basically the definiton of dependant types
<ryuukk__>
the problem is the 2 different way to achieve the same
<ryuukk__>
const MyType = struct and fun MyType(comptime T) type { .{}}
<ifreund>
ryuukk__: are you saying that a non dependant type is the same as a dependant type?
<ifreund>
cause I don't agree that those are the same
<ryuukk__>
both creates anonymous struct
mmohammadi981266 has quit [Quit: I quit (╯°□°）╯︵ ┻━┻]
<ifreund>
the later is a type dependant on T, the former is a type dependant on nothing
<ryuukk__>
the anwser i got so far is: it' to not not add new syntax
<ryuukk__>
but new syntax was added to achieve this: const MyStruct = struct {}
<kristoff_it>
ryuukk__, maybe you and the others are enjoying the exchange, but to get to the point: comptime "ducktyping" over types is one of the defining characteristics of Zig. If you don't like it, my first suggestion is to read more code (from the stdlib for example), write some of your own, and try to understand what are the advantages of this approach, since it seems to me you might be missing some of the implications when saying that "it's the same thing".
<kristoff_it>
After that, if you still consider the approach flawed, you have two options: go on GitHub, read past issues on the topic and open a new one where you argue your case why we should have angle brackets; while the second option is to just leave Zig be. I heard Rust has a pretty sophisticated type system with tons of safety. Complaining about that approach here on IRC won't really convince people because that's the path the language has been following for a
<kristoff_it>
while now and short IRC messages probably won't be enough for you to properly structure a counterpoint to that.
<ryuukk__>
instead of fun Mystruct : type { .{} }
<ryuukk__>
fun MyStruct : type { .{} } and const MyStruct = struct {}
<ifreund>
no, const MyType = struct {}; is not new syntax
<ifreund>
that's a normal variable declaration
<ifreund>
like const x = 5;
<ryuukk__>
ah good point
<ifreund>
types are first class values remember? :P
<ryuukk__>
kristoff_it: remember i am new to zig, this is my experience as i write zig code
<ryuukk__>
kristoff_it: i'm not confidering approach flawed, all i am askign is arguments so it clear my confusions
<ryuukk__>
now it's becoming a little more clear
<ryuukk__>
> while now and short IRC messages probably won't be enough for you to properly structure a counterpoint to that.
<ryuukk__>
what do you mean?
<kristoff_it>
you've also complained about it being different than what you're used to :) anyway, all is good
<ifreund>
And I for one am totally happy to continue trying to explain my views on why zig is the way it is :)
<dutchie>
i'm a few days past reading through the docs for the first time and it seems really cool so far
<ryuukk__>
kristoff_it: i said because it's not using a function, not because that's what i'm used to
<dutchie>
now if i could just work out why it's telling me the thing (I think) I only want at runtime is not available at comptime...
<kristoff_it>
dutchie, have you seen ziglearn.com? that's also another good resource
<ifreund>
happy to take a peek if you have a link :)
<dutchie>
.org?
<ifreund>
yes
<kristoff_it>
ah yes .org sorry
<dutchie>
ifreund: yeah, i was going to try to make a minimal reproduction after work today if i get a chance
<dutchie>
slacking off on irc is one thing, hacking on personal projects is another :)
<kristoff_it>
dutchie, whenver that happened to me in the beginning is because I forgot to explicitly say that my loop index var needed to be of type usize
<kristoff_it>
not specifying the size makes the compiler think that `i` should be a comptime var that I'm trying to modify at runtime
<dutchie>
i tried adding a bunch of type annotations but it still was complaining about comptime_int
<dutchie>
it's a switch
<ryuukk__>
kristoff_it: and they replied with it's to not create new syntax, wich i was confused because i had the impression const MyStruct = struct {} was already a new syntax, but i was wrong, and realized it when ifreund mentioned the variable declaration syntax, wich helped clear my confusion
<Michcioperz>
dutchie: might you be switching on a variable you assigned an int literal to but without saying what size of int it is? like `var x = 2;`
<Michcioperz>
ah, you tried adding annotations, sorry
<ryuukk__>
kristoff_it: not wanting to understand people's problem and saying "complaining about it on IRC wont convince people" i'm not trying to convince anyone, i want to clear my confusions
<Michcioperz>
i misread
captainhorst has joined #zig
<ryuukk__>
and don't be like rust people, don't just say "read the book" or "the language is not for you" or "you don't understand", because that kind of issues i didn't have with other languages
<kristoff_it>
ryuukk__, that was not the impression I got by reading the messages, but yes I might have misread/misunderstood what you said. That said, statements like "i'm not sure i like this, it doesnt make sense", "this is uneeded complexity", "everylanguage it's this way MyStruct<T> { data: T} that's it" can be seen as something more than just clearing your confusion, in my opinion.
<ryuukk__>
kristoff_it: because to me using function to create a new type is what confused me
<ifreund>
it's understandable that that's confusing at first, Zig's the only language I know of that lets you do it
<dutchie>
i guess lisps maybe?
captainhorst has quit [Ping timeout: 260 seconds]
<ifreund>
I've never gone deep into lisp world
<kristoff_it>
well if you go into higher level languages, you can pass around types in quite a few of them. In python is not even that uncommon to do it
<earnestly>
ifreund: The scrollback is too convoluted; which feature are you refering to?
<dutchie>
decided that slacking off on irc was functionally comparable to making an example: https://0x0.st/iGOD.zig
<ifreund>
types as first class values at comptime
<earnestly>
iGOD, nice slug
<earnestly>
ifreund: Ada would be one iiuc
<kristoff_it>
dutchie, you probably just need to give a type to your enum, enum(usize), for example. Somebody please correct me if I'm wrong.
<ifreund>
dutchie: .February => @as(u8, if (isLeap(self.y)) 28 else 29),
<ifreund>
this is enough to make zig's type inference happy
<ifreund>
I think you shouldn't need it though, the compiler should be able to figure things out
<dutchie>
huh, ty
<ifreund>
kristoff_it: nothing related to the enum :P
<dutchie>
should i file a bug?
<ifreund>
wouldn't hurt, probably won't ever be implemented in stage1 though
<dutchie>
not sure why the test fails now
<dutchie>
it type-checks at least, i have probably done something dumb
<ifreund>
oh yeah I saw that but didn't look into it :D
mmohammadi981266 has joined #zig
<ifreund>
well the months aren't all 31 days long, some are 30 no?
<ifreund>
wouldn't matter for that test case though :/
<dutchie>
yeah i couldn't be bothered to put all of them but i'm only testing february
<dutchie>
lol i see the problem
<dutchie>
i have the 28/29 the wrong way round
<dutchie>
now it's fine :
<dutchie>
:)
<ifreund>
nice :)
<ifreund>
earnestly: I'm not an ada user, but I don't think you can store types in variables and pass them around?
<ifreund>
at least I can't find any docs on such a feature
<ifreund>
dutchie: heh, this is actually all you need: .February => if (isLeap(self.y)) @as(u8, 29) else 28,
<ifreund>
i think the issue is with the if statement
<earnestly>
ifreund: It depends on what you mean by "storing types"
<ifreund>
yeah at compile time only of course, they have no representation at runtime or in the resulting binary
<ifreund>
but zig lets you handle them similarly to e.g. integer values in comptime code
<earnestly>
Yeah, compile time features are pretty rare in other languages and often depend on compilers being "smart enough"
<earnestly>
Probably because it makes compilation non-deterministic
<ifreund>
if you keep the inputs the same, why should it be non-deterministic?
<earnestly>
ifreund: The halting problem, much like C++'s templates and constexpr and co.
<ifreund>
indeed, we have an arbitrary max branch quota to avoid solving the halting problem
<earnestly>
I think eBPF did a similar thing, combined with not allowing loops
<ifreund>
this can be overridden and raised in in user code if needed
<earnestly>
I hope zig will get fixed point arithmetic as standard, if it doesn't. (I consider anything which doesn't to be a toy language)
<earnestly>
ifreund: You reminded me of safety critical applications and how they might have to assess compiler paths with more compile time features
<earnestly>
Which reminded me about the story of how Ada got fixed point as standard, and that story is quite harrowing
<companion_cube>
are all languages toy languages, earnestly? :p
<earnestly>
ifreund: In Ada you don't use "float" or "double". You specify the needed precision and the compiler will find the most efficient representation for you
<ifreund>
that sounds cool and also potentially complicated
mmohammadi981266 has quit [Quit: I quit (╯°□°）╯︵ ┻━┻]
<earnestly>
companion_cube: Fixed point was added to Ada as a direct result of a floating point error resulting in a missle defense system failing to detect an attack that resulted in 31 dead marines
<companion_cube>
the patriot missile?
<earnestly>
Yep
<earnestly>
Although then they had Ariane 5, so lol
<companion_cube>
interesting, didn't know that was the solution
<companion_cube>
fixed point solved it because the errors are rounded differently, I imagine
<earnestly>
Wait, Ariane 5 was prior to that
<ifreund>
fixed point is much more consistent and deterministic than floating point
<earnestly>
companion_cube: https://en.wikipedia.org/wiki/Q_(number_format) this sort of thing. Although Ada, iiuc, will use hardware float/double if it can, and it may add in epsilon code. I'm not sure
arun3rd has joined #zig
<companion_cube>
ifreund: interesting
<companion_cube>
the use case I thought fixed poiint was for is money
<companion_cube>
but even then you can just use fractions of cents in int64 or something like that, probably
<ifreund>
yes, that's certainly a good use case for it
<companion_cube>
I mean, the message passing blocks sender/receiver until the other party is there?
<earnestly>
companion_cube: Yes (but you don't have to block)
<companion_cube>
right, so that's like synchronous channels?
<companion_cube>
I'm a bit curious why no one did ada tasks as a library in rust
<companion_cube>
people seem more aware of Go-like channels
<earnestly>
companion_cube: It's more like Erlang
mmohammadi981266 has quit [Quit: Ping timeout (120 seconds)]
<earnestly>
protected types act as a mutex if you have multiple threads trying to access something like counter, e.g. https://0x0.st/iH2C.txt (simple semaphore)
<companion_cube>
hmm so you have a mailbox of incoming messages?
<companion_cube>
(your code snippets don't have colors, that's a bit sad :p)
mmohammadi981266 has joined #zig
xackus has quit [Ping timeout: 246 seconds]
<earnestly>
companion_cube: Hm, I think mailbox is a fair description
<earnestly>
The weird thing is that tasks start the moment you declare them
<ifreund>
ah TIL the name for the messed up meme text
<ifreund>
and yeah I love that zig doesn't have operator overloading
skuzzymiglet has joined #zig
<justin_smith>
ifreund: following from the general language design idea "make things you want clean and elegant, and things you want to discourage ugly and clumsy", we could use zalgo for neccessary but highly suspect zig features :D
JoshAshby has quit [Quit: WeeChat 1.2]
<ifreund>
so basically what the operator overloading equivalent is in zig: foo.add(bar);
ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #zig
gazler_ has joined #zig
wilsonk has joined #zig
<wilsonk>
ls
<wilsonk>
woops
gazler has quit [Ping timeout: 244 seconds]
wilsonk has quit [Quit: Leaving.]
wilsonk has joined #zig
<ryuukk__>
for @cInclude("GLFW/glfw3.h"); how to tell specific path? i'm on windows
wilsonk has quit [Client Quit]
<ryuukk__>
i tried to put header on the same folder, it doesn't work
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
wilsonk has joined #zig
<ryuukk__>
oh there is a exe.addIncludeDir
<ifreund>
ryuukk__: by the way, you're right that functions are inconsisent with the rest of zig syntax currently. This is planned to be fixed though: https://github.com/ziglang/zig/issues/1717
arun3rd has quit [Quit: Leaving]
wilsonk has quit [Quit: Leaving.]
wilsonk has joined #zig
wilsonk has quit [Quit: Leaving.]
wilsonk has joined #zig
wilsonk has quit [Client Quit]
mixi has quit [Ping timeout: 272 seconds]
flokli has quit [Ping timeout: 272 seconds]
<ryuukk__>
.\src\main.zig:66:9: error: expected type 'bool', found '@typeInfo(@typeInfo(@TypeOf(.glfw.src.main.init)).Fn.return_type.?).ErrorUnion.error_set'
<ryuukk__>
try glfw.init();
<ryuukk__>
i don't understand what i should do here, n init(self: *Gfx, config: *Config) bool i'm supposed to return a value, but i don't know how to do it with try
<earnestly>
ifreund: The only point of concern about operator overloading is that mathematicians essentially need it for anything actually complicated but I don't know the details
masoudd has joined #zig
<earnestly>
It's just what I've been told
captainhorst has quit [Ping timeout: 265 seconds]
<justin_smith>
yeah, I think that's a case where the preferences of a domain conflict with good language design
<justin_smith>
DSLs for math are definitely a thing
<ryuukk_>
var primaryMonitor = glfw.Monitor.primary() catch return false; <= here, is there a way to get a Monitor, and not a ?Monitor ?
<ryuukk_>
because here: glfw.Monitor.getVideoMode(primaryMonitor) it complains about receiving a ?Monitor
<ryuukk_>
error: expected type '.glfw.src.monitor.Monitor', found '?.glfw.src.monitor.Monitor'
<ryuukk_>
searching for ? is hard with google
<justin_smith>
ryuukk_: I usually use if (foo.bar()) |v| foobar = v; to unwrap optionals
<g-w1>
a orelse false;
<justin_smith>
oh that's nicer
<ryuukk_>
i don't understand
<ryuukk_>
where should i put orself false?
<g-w1>
orelse unwraps optionals. const b = a orelse return false; means that if it is not null then b is a otherwise the function returns false
<g-w1>
does that make sense?
<ryuukk_>
.\src\main.zig:78:54: error: expected optional type, found '@typeInfo(@typeInfo(@TypeOf(.glfw.src.monitor.Monitor.primary)).Fn.return_type.?).ErrorUnion.error_set!?.glfw.src.monitor.Monitor'
<ryuukk_>
var primaryMonitor = glfw.Monitor.primary() orelse return false;
wilsonk has quit [Quit: Leaving.]
<g-w1>
it seems like it expected an optional
wilsonk has joined #zig
wilsonk has quit [Client Quit]
<justin_smith>
it looks like you need to wrap the catch and the orelse around it at the same time
<g-w1>
yeah
<justin_smith>
it might be clearer if you did it in two steps via a temporary varialbe
<ifreund>
which I showed you how to do, but then you lose color
<ryuukk_>
why you told me zig build-exe?
<ifreund>
zig build-exe has an option to force color
<ifreund>
I'll just add it to zig build real quick
<ifreund>
brb
<ryuukk_>
oh i see
<ryuukk_>
but wait, the goal is to not have what's at the end, i tried with dub and rust, and it stops at process exit, it doesn't print the full command
<ifreund>
yeah? dub is a different program from zig..
<ryuukk_>
i know, i said it gets in my way when i want read the error message, so it is usability annoyance
<ryuukk_>
i have to scroll up
<ryuukk_>
or i need to make the terminal panel large enough, wich reduce size of the text panel
<ifreund>
the full command run can be very useful for debugging
<ifreund>
looks like I use a smaller font and larger terminal than you though
<justin_smith>
ryuukk_: I don't know how your tools work, but I can run zig from inside my editor, and the error messages turn into clickable links to the file locations
<ryuukk_>
maybe there could be a normal and a verbose mode
<ryuukk_>
more info is not always the best choice
<ifreund>
I too have a similar setup to justin_smith
<ryuukk_>
even if terminal is fullscreen, eye need to do movement from where you type the command, to where the message is located
<ryuukk_>
is you build, and tehre is an error, you want see the error message first
<ryuukk_>
if*
<ryuukk_>
not the command u typed/generated
<ryuukk_>
https://i.imgur.com/oQSpGbT.png take look again, the giant command and folder weird names is clutering the actually message
<ryuukk_>
what you want to see is error message, not C:\dev\kingdom_zig\zark\zig-cache\o\5d125da8c009f6f5286d7710ca64dd57\build.exe for example
skuzzymiglet has joined #zig
<ryuukk_>
that would be helfull if you want to debug the zig build tool, not your program
<ryuukk_>
i'm pretty sure cargo / dub don't show that for this specific reason, usability
<ifreund>
sure, they're also both post 1.0
<ifreund>
if you want to propose changes open an issue or pull request
<ryuukk_>
that is why i talk about it, maybe it should be considered for up to 1.0
<ryuukk_>
i don't want spam the repo if something is already planed, never discussed or not wanted
<ryuukk_>
that is why i discuss about it first
<ifreund>
yes, usability of the tooling will definietly get more focus when 1.0 is close and there is less other, more critical work to be done
<ryuukk_>
it's ok ifreund, i am looking into add an option in RunStep to not print the command
<ikskuh>
TheLemonMan: btw, i'm happy about github issues for cg-workbench, even with just improvements
<TheLemonMan>
ikskuh, what do you mean with different edge types?
<TheLemonMan>
ikskuh, I was thinking of sending a PR lowering the required GL context to 4.2 as that's what my mesa version supports atm
<ikskuh>
ah, sure
<ikskuh>
we can probably go even further down and just disable features at runtime
<ikskuh>
only GL_ARB_direct_state_access is a hard requirement
<TheLemonMan>
negotiating an opengl version is harder than it should :\
<ikskuh>
heh, true
<ikskuh>
"try 4.5, try 4.2, try 4.0, try 3.3"
<ikskuh>
:D
<ikskuh>
edge types: edges transport data between nodes, "f32, vec2, vec3, texture, …"
<ikskuh>
and even if you can't see it right now (as it's disabled), the project is actually fully plug-in capable
<g-w1>
in zigup, it seems that it automatically uses /home/user/bin/zig I use .local/bin/ as my go to path, is there a way to do this, or should i file an issue?
<ikskuh>
extending with new node types like audio, including FFT
<TheLemonMan>
oh I see
<g-w1>
never mind
<ryuukk_>
hmm i made changes to `C:\zig\lib\zig\std\build\run.zig` but it doesn't seems to work
JoshAshby has joined #zig
<ryuukk_>
do i need to do something specific for changes to apply?
xackus has joined #zig
<ifreund>
nope
<TheLemonMan>
it should pick them up automagically
<ifreund>
try a print statement or something
<ryuukk_>
oh changes must be made in build.zig
<ryuukk_>
C:\zig\lib\zig\std\build.zig
<ifreund>
well std/build.zig @imports std/build/run.zig
<TheLemonMan>
you didn't run zig fmt over the files you changed!
<ryuukk_>
i follow same code style, is something wrong?
<g-w1>
if(self.verbose_build)
<TheLemonMan>
^^^ yep
<ryuukk_>
oh my bad
<earnestly>
Wait, your PR removes the invocated command-line and its flags?
<g-w1>
I think it adds a flag
<earnestly>
Oh good, it's like all those Makefiles that removes the actual command-line and hides it behind a useless 'CC' so that I have to hope it has some VERBOSE flag so that when I rerun the command I get /real/ information
<earnestly>
I just love it when tools tell me "Sorry, I failed. You should have run me with some verbose flag so I actually give you useful diagnostics"
<ryuukk_>
it is now an option, it is only usefull when you debug the build tool in my opinion, you have your commands in the build.zig file
<ryuukk_>
maybe i have wrong assumption and it shouldn't be even an option, it's possible, but i find the ouput cleaner now
<earnestly>
How a command expands is not reflected in a build.zig
<ifreund>
yeah I'm not sure this should be disabled by default
<ryuukk_>
the verbosity adds clutter and hides actual error message in your program
<earnestly>
This kind of crap is something that has wasted hours of my life
<ryuukk_>
it would if it wasn't an option
<earnestly>
ryuukk_: Make it not default, include a 'be quiet' flag rather than a 'be verbose' one
* TheLemonMan
takes out the popcorn
<ryuukk_>
looking for error message each time you build actually might waste u more hours
<earnestly>
Tools should always fail loudly, but otherwise be silent
<earnestly>
(ideally)
<earnestly>
ryuukk_: Fortunately we have tools that make searching through textual information a doddle
<earnestly>
It's not so much fun when that information isn't there in the first place
<earnestly>
And ensuring path location hasn't gone ary is one of the most /key/ pieces of information I need, especially when integrating into wonky systems
<ryuukk_>
why would everyone pay price of verbosity by default? when all care about is looking for compiler output when build your program
<earnestly>
It gets even worse in CI systems, where fortunately things like cmake do allow me to use `make VERBOSE=1' but that it's not the default is just anti-user
<earnestly>
ryuukk_: There's no price, verbosity is only used in diagnostics, i.e. when you need it to be verbose
<earnestly>
It's the "rule of silence"
* jabb
joins lemon
<ryuukk_>
exactly, diagnostic, you must be explicit for more informations
<ryuukk_>
it's not silence, you get the error message about your program
<ryuukk_>
that's the main information you need
<earnestly>
Yours removes part of that message
<ifreund>
he means verbosity only on failure, your PR removes much of the verbosity of failure
<ryuukk_>
no
<ryuukk_>
.\src\main.zig:80:70: error: expected optional type, found '*const .glfw.cimport:6:5.struct_GLFWvidmode'
<ifreund>
on success it should always print nothing
<ryuukk_>
is all i care about when i want build my code
<ifreund>
but that's not what people packaging your code care about
<ifreund>
or at least potentially not
<ryuukk_>
do you package code more often than build your code?
<earnestly>
ifreund: It's part of it yeah
<ifreund>
no, but packagers shouldn't need to be familiar with all the zig command line options to get useful diagnostics on failure
<earnestly>
ryuukk_: Yes
<ifreund>
zig developers however should be capable of passing an extra flag if they want quieter output
<ryuukk_>
packagers should knock at door and ask for more informations
<ifreund>
earnestly definitely does, I don't but I do maintain a handful of packages
<ifreund>
ryuukk_: that's exactly what we don't want
<earnestly>
ifreund: This kind of thing is what makes me want to stop doing it
<ryuukk_>
what would be packager job if there would be no developpers to write and build the code?
<ifreund>
we want packaing zig code to be as easy and intuitive as possible
<ryuukk_>
but is clutter the job of developper to build and debug the code
<Nypsie[m]>
What problem does this solve if we have multiple errors, with multiple stacks?
<ryuukk_>
zib build pacakge, and put the verbose option there
<ryuukk_>
zig build package
<earnestly>
ryuukk_: Why not a quiet flag instead?
<ifreund>
^
komu has joined #zig
<ryuukk_>
what is a quiet flag?
<ifreund>
the opposite of what your PR does
<g-w1>
zig build --quiet
<ifreund>
keep it verbose by default, add a flag to make it less verbose
<ryuukk_>
i know what it is i wanted you to explain me, what quiet in context of build?
<ifreund>
less verbose
komu has quit [Remote host closed the connection]
<ryuukk_>
why have build.zig then?
<ryuukk_>
printing commands = i want to debug the build.zig
<ryuukk_>
not my program
<earnestly>
So use quite flag to not print them?
<TheLemonMan>
build.zig may contain complex pipelines and you want to know exactly where it got messed up
<ryuukk_>
it's not always the case, when specific needs, use verbose flag
<TheLemonMan>
defaults matter
<ifreund>
especially for distro maintainters who are not zig developers
<earnestly>
It's no good trying to debug a transient error when faithful error reporting can only be requested after the fact
<ryuukk_>
for specific needs, specific options
<ifreund>
exactly. Hiding output is a specific need
<TheLemonMan>
wait, I'll side with ryuukk_ so we can have a healty 2vs2 fight
<ryuukk_>
path of cache? it's in the current folder
<ryuukk_>
this folder? 5d125da8c009f6f5286d7710ca64dd57\build.exe why?
<ifreund>
that's the full zig build-exe command line generated by your build.zig
<ryuukk_>
path of the project you compile? you are in it already
<Piraty>
argh i hate backslash. so glad i didn't had to touch a windows machine in months
<ryuukk_>
cann't say this is usefull, on first sight, can't decode 80% of it because weird paths
<ryuukk_>
if need more info, read build.zig
<ifreund>
which may be non trivial to determine based on reading the build.zig
<ryuukk_>
if suspect bug, add verbose
<ryuukk_>
all it does is hide error message of your program
<ifreund>
this isn't really going anywhere, I'll paste a log as a comment on the PR and let the andrew decide
<ifreund>
though he probably has better things to do in the last 2 weeks before a release
<ryuukk_>
there is IRC log, not need put specific comment, full context is better
<ifreund>
yes I will link to the logger
<ryuukk_>
I added it
KernalWayne has joined #zig
azeqsd has joined #zig
<ryuukk_>
that information only needed once, when you change build.zig
<ryuukk_>
then never again u need it
<KernalWayne>
Having done build engineering in the past, verbose output should definitely be the default, IMO.
<ryuukk_>
provide arguments why you need information that doesn't change everytime you build program?
<ifreund>
it may not change in your specific environment with simple build.zig, but it may very well change once you introduce build options and have people compiling on different OSes
<ryuukk_>
specific need, only needed once, when you package it once
<ifreund>
I don't feel like this is going anywhere though, I'm going to go be productive
osa1 has quit [Ping timeout: 260 seconds]
<ryuukk_>
why stop when i ask for arguments?
<ryuukk_>
> I don't feel like this is going anywhere thoug
<ryuukk_>
maybe packager need the time, so we should print the date when it built, otherwise he can't type in read me when it built? (of course this is a troll, but this is relevant)
<ryuukk_>
maybe should also print all environment variable, because it can impact build?
<ryuukk_>
maybe OS name / ketnel version in case he forgot it
<ifreund>
none of that information is related to zig
<ifreund>
well, printing a message when an environment variable affects the build is a great idea and what sane build systems do
<ifreund>
but that's orthagonal to the issue at hand
<ryuukk_>
the point is it's information that doesn't change and is needed only once
<ifreund>
it can and will change depending on the build environment and options passed to zig build
ryuukk__ has joined #zig
<KernalWayne>
The info may be needed potentially every time the code is built.
<KernalWayne>
Maybe not by you during development, but by package/distro maintainers, etc.
marnix has quit [Ping timeout: 258 seconds]
<KernalWayne>
Or in a team setting, other developers.
ryuukk_ has quit [Ping timeout: 256 seconds]
ryuukk_ has joined #zig
azeqsd has quit [Remote host closed the connection]
ryuukk__ has quit [Ping timeout: 240 seconds]
ur5us has joined #zig
<ryuukk_>
ok so let's rewind a little bit and examine the issue:
<ryuukk_>
[7:32:08 pm] <ryuukk_> it makes it hard to just look at the actual error message
<ryuukk_>
maybe reordering the output would help?
<ryuukk_>
1st the command, the the stack trace?
<ryuukk_>
maybe still print the command, but ommit the rest?
<KernalWayne>
As long as the diagnostic info remains present. Code isn't always built by someone sitting in front of a terminal.
<KernalWayne>
Think about automated builds that may be diagnosed after the fact by examining logs.
<KernalWayne>
Nobody in that situation wants to rerun a build and add a flag to get more info.
<KernalWayne>
They want to fix the problem with the info at hand.
<ryuukk_>
reordering the ouput then is the way to go?
marnix has joined #zig
<ryuukk_>
no matter how long the ouput is, people can see it, and the error message is easier to read, not more scroll up
<KernalWayne>
Perhaps. I just don't think it's a good idea to make things "quiet" by default.
<KernalWayne>
A lone developer my find that case useful for the reasons you suggest.
<KernalWayne>
But in just about all other cases, verbosity is more valuable.
<ryuukk_>
i don't like quiet word, that imply something is noisy or print constant and lot of uneeded information, i'm not saying the command like is unneeded information, all i'm saying is it's not needed everytime
<ryuukk_>
imagine you link ton of libraries, becomes 10 lines of information, your program error message will be way above, out of the actual context
<ryuukk_>
long path + long library names, enough to make stuff even more clutered
<ryuukk_>
so i think, reordering the info would be a fair change
marnix has quit [Ping timeout: 256 seconds]
<KernalWayne>
That's reasonable. Nothing wrong with examining how the output is ordered/presented and making it more useful for everyone.
skuzzymiglet1 has joined #zig
skuzzymiglet has quit [Read error: Connection reset by peer]
KernalWayne has quit [Remote host closed the connection]
Akuli has quit [Quit: Leaving]
wootehfoot has joined #zig
wootehfoot has quit [Client Quit]
wootehfoot has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
captainhorst has joined #zig
<jabb>
looking at old zig code, can't remember what `param: var` means in new zig
<TheLemonMan>
param: anytype
<jabb>
ahh yes
<ryuukk_>
how does it know its size of anytype, it is a comptime feature?
<ifreund>
it is comptime only yes
<TheLemonMan>
hm? the anytype is replaced by the actual type on instantiation
<ryuukk_>
what would be use case? it is not what generic do?
<ikskuh>
ryuukk_: that's how generics work in zig
<ikskuh>
you either specialize params on a previous type parameter or you use anytype params
<ifreund>
TheLemonMan: last I checked you could put comptime anytype fields in structs, which is kinda weird
<ifreund>
almost made building tuples possible
<ikskuh>
ifreund: tuples are just structs
<TheLemonMan>
I guess it's just a missing check in stage1
<ikskuh>
anytype fields in structs are the same as in tuples