ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
byronh__ has quit [Ping timeout: 245 seconds]
byronh__ has joined #zig
<byronh__>
Clownpriest, what do you mean?
<clownpriest>
3.add(4)
<clownpriest>
just thinking about how you might want to abstract something like addition into an interface
<clownpriest>
have a function called add() that accepts anything that's add-able
<clownpriest>
just as a toy example
<andrewrk>
what's the use case for such a function?
<clownpriest>
i mean, it's just a toy example
<clownpriest>
but even as a toy, it would be nice to be able to add an i32 to a usize, tho i know why that's potentially a bad idea
<andrewrk>
you can do that, you just have to explicitly cast your i32 to usize, which asserts that it is non-negative
<clownpriest>
right
<andrewrk>
why do you have an i32 if it's never negative?
<clownpriest>
because i got handed an i32, not my choice
<clownpriest>
from some library i'm using
<clownpriest>
(hypothetical)
<andrewrk>
at the moment you are handed an i32, you should check if it is negative, return an error if it is, otherwise cast it to u32 (or u31 even)
<andrewrk>
it casts an integer to another type, returning error.Overflow if it cannot be casted
<clownpriest>
very cool, thanks for this link
<andrewrk>
if it's a C API, and the documentation states that the value will never be negative, then actually the .h file is wrong, and it should be u32, not i32
<andrewrk>
at which point you may consider doing translate-c offline, and then patch up the extern fn declaration
<clownpriest>
i mean in zig-zig code
<clownpriest>
and purely as a hypothetical toy example
suirad has joined #zig
<clownpriest>
the larger point is about contracts between types and operations over those types
<andrewrk>
in your hypothetical example, an API author has chosen the wrong type for an integer. it makes sense then that trying to use their API means you have to perform an undesirable cast
<clownpriest>
what if i have Vec3's and Vec5's and i want to have a single add() function to handle both of them
<andrewrk>
sounds like you want to use `var` parameter types and comptime reflection
<clownpriest>
which is what bheads' solution is suggesting
<clownpriest>
that add(x: var) would check that x has a function called "add" and any other conditions it needs to assert
<clownpriest>
in which case, my question is just, why shouldn't add(x: var) also be able to take an i32
<andrewrk>
I think APIs are generally nicer if you use explicit types for everything, and resort to generics only when it solves a specific problem
<clownpriest>
yeah
<clownpriest>
you're most likely objectively right
<clownpriest>
i'm just so tempted....
<clownpriest>
and seems like things like serialization can be pretty nifty with that kind of power (see rust's serde crate)
hoppetosse has quit [Ping timeout: 264 seconds]
<clownpriest>
all that said....i think the drive towards minimalism in the language is of critical importance
<clownpriest>
kinda feel like a drug addict after all those other bloated languages tho
<clownpriest>
i have tasted the sweet milk of unbridled abstraction
<clownpriest>
this is one of my favorite tech talks ever
<clownpriest>
all programming is data transformation
dbandstra has joined #zig
<clownpriest>
the Q&A at the end was pretty funny
<clownpriest>
language lawyer who's drank the c++ kool aid: "but mike, what about abstraction?"
<clownpriest>
mike: "your templates will not save you from yourself"
<clownpriest>
"(or the hardware)"
<clownpriest>
thank you for the reminder
<dbandstra>
andrewrk: thanks for adding || to the docs, i think you forgot to add it to the table of operators though (and the precedence section). btw are there any other undocumented operators?
<andrewrk>
dbandstra, ah, thanks, I'll do that tomorrow. looks like || is the only missing one
byronh__ has quit [Ping timeout: 240 seconds]
sagecode has quit [Ping timeout: 256 seconds]
dbandstra has quit [Quit: Page closed]
donlzx has joined #zig
bheads has quit [Ping timeout: 240 seconds]
mahmudov has quit [Ping timeout: 248 seconds]
dbandstra has joined #zig
bheads has joined #zig
bheads has quit [Remote host closed the connection]
return0e has quit [Remote host closed the connection]
bheads has joined #zig
return0e has joined #zig
kristate has joined #zig
bheads has quit [Read error: Connection reset by peer]
kristate has quit [Remote host closed the connection]
clownpriest has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
gavanw has joined #zig
kristate has joined #zig
kristate has quit [Ping timeout: 248 seconds]
JinShil has joined #zig
very-mediocre has joined #zig
xtreak has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
gavanw has quit [Quit: Page closed]
xtreak has quit [Ping timeout: 256 seconds]
kristate has joined #zig
dbandstra has quit [Quit: Leaving]
kristate has quit [Remote host closed the connection]
jjido has joined #zig
alexnask has joined #zig
<alexnask>
@andrewrk Congratz on going full time on zig
<alexnask>
Haven't been around lately, I have to study for my finals, I will be back with more metaprogramming nonsense after I take them :P
<alexnask>
Personally I would love a weekly zig livestream btw, especially if it's focused on a single project (like a game or something), I think this kind of content is getting more and more popular
davr0s has joined #zig
suirad has quit [Ping timeout: 260 seconds]
juturnas has joined #zig
kristate has joined #zig
<juturnas>
I'm trying to pass an extern zig function as a callback to a C function, and I'm getting the error "error: cast discards const qualifier". I understand why the pointer to a zig func is const, but what do I need to do to hand that off to a C function that isn't expecting a const pointer?
<alexnask>
@juturnas I don't think a zig function pointer should be const
<alexnask>
Can you show the code please?
<alexnask>
I may be wrong though, you could accept a const function pointer in your function prototype to work around it
<juturnas>
I'm not 100% sure I understand where the const comes into play
<alexnask>
Right, the function pointer is probably const for sure
<alexnask>
Though I'm not sure what the purpose of the @ptrCast is here?
<alexnask>
'callback' is already of the type you are trying to cast to (well, if we ignore the constness for a second)
<juturnas>
`/Desktop/zigfilter/zf.zig:45:52: error: expected type '?[*]extern fn(?*struct_nfq_q_handle, ?[*]struct_nfgenmsg, ?*struct_nfq_data, ?*c_void) c_int', found '*const extern fn(?*struct_nfq_q_handle, ?[*]struct_nfgenmsg, ?*struct_nfq_data, ?*c_void) c_int'`
very-mediocre has joined #zig
<alexnask>
Hmmm
<juturnas>
Trying to address the difference between those two signatures with the cast
<alexnask>
I'm not too familiar with the new pointer syntax but * should implicitely convert to [*] so the issue is probably still the constness
<juturnas>
rog
<juturnas>
This is the first real zig code I'm writing - can I throw that cast or function call into an unsafe block for now as a workaround?
<alexnask>
I don't think you can discard the const, the best workaround is probably to write the prototype yourself, although this should work out of the box
<juturnas>
Ahh gotcha, I didn't realize that was an option, makes sense though
<alexnask>
@juturnas you can use zig translate-c
<alexnask>
Instead of directly using @cImport, if you need to modify signatures
<alexnask>
Also, the C functions probably expect a 'stdcallcc' func pointer
<alexnask>
This is probably not an issue if you're running on x64 though, the default calling convention should be equivalent to stdcallcc on all major platforms
<alexnask>
Just saying though
<alexnask>
Oh, nvm, 'extern' should do the trick, stdcallcc is a windows thing
<juturnas>
Interesting, thanks for the info
<alexnask>
Hit me up if you have any issues. I definitely think this would be worthy of an issue on github, people shouldn't have to manually modify signatures to use C functions that expect callbacks
<juturnas>
will do, thanks
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kristate has quit []
donlzx has quit [Quit: Leaving]
davr0s has joined #zig
juturnas has quit [Ping timeout: 260 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
JinShil has quit [Read error: Connection reset by peer]
alexnask has quit [Ping timeout: 260 seconds]
davr0s has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
alexnask has joined #zig
very-mediocre has joined #zig
quc has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
byronh__ has joined #zig
<GitHub104>
[zig] tiehuis opened pull request #1105: Add i128 compiler-rt div/mul support (master...i128-compiler-rt) https://git.io/vhKtG
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
sagecode has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
very-mediocre has joined #zig
alexnask has joined #zig
mahmudov has quit [Ping timeout: 264 seconds]
noonien has joined #zig
<andrewrk>
alexnask, hmm maybe we should translate-c function pointers into * instead of [*]
<andrewrk>
btw * does not implicitly cast to [*]
sdfsdfsf has joined #zig
clownpriest has joined #zig
<alexnask>
@andrewrk Is there any reason why it shouldn't? Does [*] there is more than one element pointed to (I though it meant you have to treat it as an array, but that doesn't mean that the array has more than one element imo)
<andrewrk>
it does allow *T to *[1]T to [*]T
<andrewrk>
[*] means it is "unknown length"
<andrewrk>
my only concern is if allowing it would ever cause a bug
Hejsil has joined #zig
<alexnask>
Hmm
<andrewrk>
it is unfortunate about juturnas's example. I hope they will not be scared away
<andrewrk>
I don't consider the ergonomics of the code they had to write acceptable
JinShil has quit [Quit: Leaving]
<bheads__>
is this something a lib function could help with ie: typecons.stripConst(comptime T: type) T
<bheads__>
or typecons.castToCFunctionPtr ?
<andrewrk>
bheads__, that suggestion ignores the root cause
<bheads__>
fair enough
<andrewrk>
there could be a function for converting *T to [*]T. maybe that's enough
<bheads__>
wouldnt ptrCast do that?
<bheads__>
just need a better way to write the dest pointer type
<andrewrk>
I'm probably going to remove ptrCast and add ptrElemCast, which only takes the new child type
<GitHub36>
zig/master fc87f6e Andrew Kelley: fix race condition bug in test harness of std.atomic
davr0s has joined #zig
hoppetosse has joined #zig
clownpriest has joined #zig
bheads_ has joined #zig
bheads__ has quit [Ping timeout: 260 seconds]
clownpriest has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
clownpriest has joined #zig
quc has quit [Ping timeout: 255 seconds]
mahmudov has joined #zig
very-mediocre has joined #zig
clownpriest has quit [Ping timeout: 260 seconds]
quc has joined #zig
jjido has joined #zig
hoppetosse has quit [Ping timeout: 264 seconds]
hoppetosse has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ManDeJan has joined #zig
sagecode has quit [Ping timeout: 248 seconds]
<ManDeJan>
Hello everyone! I want to try zig out but I'm unable to download the binaries, is the linux download broken for anyone else? https://ziglang.org/download/
<andrewrk>
hi ManDeJan. I'll take a look
<edr>
it worked for me, maybe try clearing your cache?
<mahmudov>
prebuilt binaries needs to llvm for runtime ?
<mahmudov>
i have llvm 4.0.0, i think for compile it needs 5.x but for run ?
<andrewrk>
mahmudov, the prebuilt linux binary is 100% static. it will work on any linux
isd has joined #zig
dbandstra2 has joined #zig
<dbandstra2>
what would be the best way to read a packed struct from a file, then use the values from the struct, where the struct fields might not be aligned? (e.g. u32 after odd number of u16s)
<andrewrk>
dbandstra2, in general I would recommend using normal structs, and then carefully parsing the file a field at a time, validating user input along the way
<bheads_>
it would have the same alignment as the struct that wrote it, but if you writing the bytes of a struct direct to disk it should be 1 byte aligned
<dbandstra2>
andrewrk: ok
ManDeJan has joined #zig
ManDeJan has quit [Client Quit]
ManDeJan has joined #zig
ManDeJan has quit [Client Quit]
ManDeJan has joined #zig
davr0s has joined #zig
ManDeJan has quit [Ping timeout: 264 seconds]
noonien has quit [Quit: Connection closed for inactivity]
<andrewrk>
dbandstra2, yeah, what's the point of coroutines if you're not doing async I/O ?
<dbandstra2>
you could walk through files in the zip archive without allocating a whole list of them
<dbandstra2>
the scan-zip function could just yield them as it reads through the archive
<andrewrk>
you can do that in a blocking fashion, without coroutines
hoppetosse has joined #zig
<dbandstra2>
you're right. i haven't actually read about coroutines yet
<very-mediocre>
I was referring to epoll
<very-mediocre>
doing that cross-platform is hairy
<very-mediocre>
checking the code you linked now
<very-mediocre>
ah i see you're implementing it for linux only for now
<very-mediocre>
okay
<very-mediocre>
*nix rather
<andrewrk>
linux only, for now, that's correct
<andrewrk>
I'm planning on having the self hosted compiler fully take advantage of coroutines and async I/O, so it'll get battle tested
<andrewrk>
on all supported platforms
<very-mediocre>
i noticed someone here was importing the C libevent the other day, that's why I asked what you had in mind for an event loop
<very-mediocre>
makes sense!
<andrewrk>
certainly an event loop in the std lib that does not depend on libc or any other third party code
<very-mediocre>
you know, when you think about it, what used to be considered pretty involved projects are kind of "solved" these days and it's just a matter of implementing, so yeah, maybe not that huge an undertaking after all
<very-mediocre>
i think that's why zig is appealing actually, there's a LOT of "solved" things but nobody put them together coherently
ManDeJan has quit [Read error: Connection reset by peer]
ManDeJan has joined #zig
<andrewrk>
exactly
<very-mediocre>
(and zig does that)
<andrewrk>
zig is nothing now, it's just engineered very carefully
<andrewrk>
*nothing new
<andrewrk>
except for error return traces! error return traces are new and someday people will be raving about them
alexnask has quit [Ping timeout: 264 seconds]
<zignoob>
'there's a LOT of "solved" things but nobody put them together coherently' rewrite it in rust tries to do that?
<ltr__>
how i see zig, an the reason why cought my eye in the first place, is that i can imagine very clearly how things would be implemented in C, it has the same ergonomics, but saves you a lot of boilerplate. the faster i can translate one language in my mind to C the better.
<very-mediocre>
That's a good answer since so many languages are based on C
<very-mediocre>
I gave it some thought, a lot of times when implementing something I'm not happy with it because it isn't optimal
<very-mediocre>
I think elegance is how close code is to optimal in terms of software design
<very-mediocre>
merits like correctness, safety, performance etc follow from that
<andrewrk>
I realized the debug safety I wanted to do is fundamentally impossible, so now I have to decide, still do it, but have imperfect safety, or give up and re-evaluate
<mahmudov>
cool andrewrk, thnks +1
<zignoob>
I'm currently reading zig docs some more, https://ziglang.org/documentation/master/#OpaqueType sounds interesting but the test is failing? Is it possible to use it the same way as type foo int in golang where foo is like an int but can't be passed to functions that expect an int, only to ones that expect foo?
<andrewrk>
zignoob, that code is demonstrating the useful compile error that @OpaqueType produces for certain types of mistakes
<bheads_>
andrewrk, I would put it on hold, give it a day or two then come back and re-review. Your not going to solve the aliasing problem that easy :)
<mahmudov>
andrewk if i download once staitc binary of zig so i can produce the next releases with it ? according to s2 or s3? is it suggestible?
<mahmudov>
static*
<zignoob>
ok, is there any zig idiom to reproduce a similar effect?
<andrewrk>
mahmudov, I am sorry, I do not understand your question. I recommend the static build of master branch.
<very-mediocre>
mind if I ask why passing non-copyable things implicitly is beneficial?
<andrewrk>
zignoob, I suggest creating a struct with the type as a field
<zignoob>
ok thats the c way of doing it
<mahmudov>
i mean if i download the prebuilt binary of 0.x so with using this static binary can i compile the zig 0.x+1 (next releases)
<andrewrk>
mahmudov, zig is not yet self-hosted. You would be downloading a binary compiled from C++ source.
<mahmudov>
Build Self-Hosted Zig from Zig Source Code - iread this
<andrewrk>
> Note: Stage 2 compiler is not complete. Beta users of Zig should use the Stage 1 compiler for now.
<mahmudov>
hm ok clear, andrewrk +1
<bheads_>
looking at 733, I think D pure functions solved this issue, but thats not a path I would want to go down
<bheads_>
D pure functions are ones that dont cause side effects, ie they dont change params or global data
<andrewrk>
very-mediocre, the most common function parameter wants these semantics: I either want a small byvalue item, or a pointer to a larger item. If it's a pointer, I promise that I will not, directly or indirectly, modify the bytes of it
<andrewrk>
the closest we have now is: *const T but this does not allow a small byvalue item, and it also does not contain the promise of not indirectly modifying it
<very-mediocre>
nim lets you mark functions as pure
<andrewrk>
I've read about pure functions in D. we want this parameter type in non-pure functions too
<very-mediocre>
but that's still the user having to BYOS (bring your own safety)
<zignoob>
about your issue, why can structs only be passed as pointers?
<andrewrk>
to avoid this issue
<zignoob>
if you pass by value you have no side effects so the issue does not even exist?
<andrewrk>
if I can solve this issue and a couple more big ones, we will get to the point where it is guaranteed the only memcpy's that zig would generate would be in variable declarations
<andrewrk>
if you pass by value, then there is a hidden memcpy
<andrewrk>
and then you have programmers wondering whether they should make struct parameters pointers or not
<zignoob>
yes that is bad so you just prohibit this for performance reasons
<andrewrk>
instead they should be thinking about what semantics they want, and the compiler can choose the best way to represent that
<zignoob>
yes so one way a friend of mine designs his language is making them pointers in the compiler so you always pass by ref and then the compiler optimises for you
<zignoob>
I mean you always pass by values unless you want side effects
<zignoob>
that is aligned with the general semantics one would expect from pointers vs values
<bheads_>
maybe dont let allow a global to be passed by value
alexnask has joined #zig
<bheads_>
so globals cannot be passed by const ref
isd has quit [Ping timeout: 256 seconds]
<bheads_>
if you really really want to, then you would have to do an unsafe ptr cast
<andrewrk>
I think I'm going to just make this change, put some safety in, and the stuff that zig can't catch is undefined behavior
<very-mediocre>
that sounds reasonable
<very-mediocre>
what you're looking for is "no side effects" and that's not a solved problem except if you're Rust or FP
<andrewrk>
there's plenty of undefined behavior zig can't catch, for example a pointer to a stack variable outliving the function
<bheads_>
yeah that one sucks
<andrewrk>
we can get better safety with more advanced flow analysis, but never perfect
<bheads_>
though there are ways to prevent that
<bheads_>
but most ways I have seen are not zen
<very-mediocre>
if you wanna do it like nim
<very-mediocre>
the compiler would complain that "innocent_function" can cause side effects
<very-mediocre>
dont_modify_param would be labeled as pure / not causing side effects
<very-mediocre>
any functions called inside it would have to have that annotation too
<very-mediocre>
it's "infectious" purity
<bheads_>
same as D
<very-mediocre>
right
<very-mediocre>
pure functions are a really good habit
<very-mediocre>
i accidentally make most of my functions pure
<bheads_>
but const refs need to work with impure functions
<very-mediocre>
or pure-ish, like I have a lucid idea of the side effects and try to contain them
<very-mediocre>
yes it's very much a programmer initiative to mark a function as pure
<very-mediocre>
it's opt-in safety
<very-mediocre>
in a sense it's better than not having it at all, then you'd be making your functions pure on your own, without the compiler helping you
<very-mediocre>
but it also introduces a new keyword or annotation, which might bloat the language.
<andrewrk>
there's a related concept that we might add in zig, which is whether you want the compiler to evaluate a function at comptime at a given callsite, if it happens to know all the args at comptime
<andrewrk>
for example you would want std.debug.assert to have this property
<bheads_>
or a logger
<andrewrk>
it would catch more bugs at compile-time
<andrewrk>
a logger? how can you log something at compile-time?
<bheads_>
I mean have the compiler catch thats a logger is pure
<zignoob>
for example you would want std.debug.assert to have this property || yes that sounds like it'd make a lot of sense
<very-mediocre>
i don't think it's possible for a compiler to infer purity
<andrewrk>
you would also want pure functions to have this property, probably
<andrewrk>
zig used to infer purity
<very-mediocre>
i mean in a useful way
<very-mediocre>
like if you already have no possible side effects
<very-mediocre>
what good is identifying it as pure at this point?
<very-mediocre>
or am i misunderstanding
<andrewrk>
then you know that you can evaluate it at compile time at a callsite if you know all the args
<very-mediocre>
oh, sure, I get it now
<bheads_>
ah yeah
<very-mediocre>
I'm still stuck on the other issue
<bheads_>
I was too
<very-mediocre>
if you're gonna add a purity keyword for that comptime feature
<andrewrk>
e.g. if we remove T.Child and expect users to use `comptime std.meta.Child(T)`, it's unfortunate that it requires `comptime`. zig should figure out to eval that function at compile time and just let you do std.meta.Child(T)
<very-mediocre>
could it double as a way to mark functions pure?
<andrewrk>
I haven't given up on having zig figure it out implicitly
<bheads_>
whats about marking the function signature as comptime ?
<andrewrk>
bheads_, that sounds like it would require the function to always run at comptime\
<bheads_>
right, some function you would want to
<very-mediocre>
couldn't you mark functions as impure (innocent_function)
<very-mediocre>
and keep note of what variables are affected by it
<andrewrk>
did you see the examples that I posted?
<very-mediocre>
yes but I don't fully grasp the AtomicRmw API
<very-mediocre>
so I didn't catch everything
<very-mediocre>
(assuming you're talking to me)
<very-mediocre>
(now I think you weren't, lol)
<andrewrk>
I was - I'm pointing out that it's not straightforward to know what variables are affected
<very-mediocre>
I see
<bheads_>
yeah... pointers in structs and globals as your pointed out makes things tricky
<very-mediocre>
the indirection of `modify` ruins it?
<bheads_>
I do have to take off for the day, later all
<very-mediocre>
wouldn't modify be marked as impure first
<very-mediocre>
and then taint `innocent_function` with the same impurity
<very-mediocre>
+ any additional impurity that innocent_function might do (not featured in this example)
<very-mediocre>
i get that modify is general
<very-mediocre>
so it's hard to tell it affects global_array
<very-mediocre>
but it's still impure
<very-mediocre>
by virtue of assigning
<very-mediocre>
but at the callsite in innocent_function, it becomes clear, no?
<very-mediocre>
like 1. modify has side effects on its 1st parameter; 2. a function that calls modify(1st param) becomes impure toward that 1st param as well
<very-mediocre>
at this point we know innocent_function has side effects on global_array
isd has joined #zig
<very-mediocre>
I'm in a weird timezone and it's really late here, so I'm gonna call it a night
<very-mediocre>
keep up the good work, andrewrk :)
very-mediocre has quit [Quit: Page closed]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bheads has joined #zig
zignoob has quit [Ping timeout: 260 seconds]
Ichorio has quit [Ping timeout: 240 seconds]
dbandstra2 has quit [Quit: Page closed]
alexnask has quit [Read error: Connection reset by peer]