<darithorn>
the top most just says "std.debug.warn("exec failed")" from std/build.zig line 779
<andrewrk>
there should be something else above that
<via>
is there any way to use lto with a c library built with gcc (and -flto) and a c library built with zig? when i try, the resulting binary actually just has a 0-sized program segment
<scientes>
> <andrewrk> zig's dwarf info code is not sophisticated enough to handle optimized builds yet
<scientes>
ahh that's why its failing when it tries to debug stage1 for me
<andrewrk>
if you're interested in improving std/debug.zig it might be fun. dwarf is a standard with a PDF explaining everything
<scientes>
that's why you had to remove that abort() from my patch
<andrewrk>
right
<daurnimator>
"fun" "dwarf"
<daurnimator>
dwarf contains a full turing complete VM
<scientes>
I actually feel debugging native code is a much better experience than interpreters/JITs
<daurnimator>
you can do a *lot* in dwarf
<scientes>
the problem with making a new interpreter or JIT is that you have to write that stuff all over again
<andrewrk>
via, I believe this is the first time this use case has been brought up, trying to do LTO across zig and non-zig code
<andrewrk>
probably should be an issue. I can foresee a lot of potential problems with it
<scientes>
yeah that doesn't sound like a very good idea
<scientes>
not that it isn't possible
<scientes>
it just sounds scary
<daurnimator>
scientes: what?
<scientes>
The C ABI really isn't that bad if you know what it is when you write to it
<daurnimator>
scientes: I'm not sure what your comment is in reference to
<scientes>
or maybe I misunderatnd what LTO is
<daurnimator>
scientes: LTO is link time optimization. you emit your object files with all sorts of extra data to tell the LTO what it is allowed/not allowed to do
<scientes>
is it the same thing as profile guided optimizations
<scientes>
and its still just a sub-set, it isn't -fprofile=full
<daurnimator>
and then when your objects are linked together to form e.g. an executable, the LTO is able to e.g. inline a function across object file boundaries
<daurnimator>
scientes: profile guided optimization is usually about finding which branches/code paths are common and recompiling with hints to make the branch predictor happy
<via>
for my project its been pretty helpful, i can have all these little functions like disable_interrupts, and nest it in wrapper functions and nest it deep, but it still bubbles up as just the single assembly instruction to disable interrupts
<via>
rather than 4 branches and returns
<scientes>
yeah but LTO is a funny term that brings many differn't things together
<daurnimator>
scientes: not really
<daurnimator>
LTO is optimization passes that happen at link time
<daurnimator>
as oppose to compile time
<scientes>
but its not the same as making all functions "static", that is -fprofile=full
<via>
i would also call it whole program optimization
<via>
automatic inlining across object file boundaries
<scientes>
via, but it isn't that
<via>
i mean, it does do that
<scientes>
it doesn't analyze *everything*
<scientes>
only a subset that is deemed to get the most benifit
<scientes>
so its really just a set of optimizations that only can be done on the whole program
<daurnimator>
isn't that exactly what optimization does?
<via>
the compiler heuristics are still used to determine what should be optimized, sure, but it does do it across object file boundaries
<andrewrk>
via, if your code is pure zig then it has whole program optimization because it only makes 1 object file
cheesy has quit [Quit: zzz]
<scientes>
so it would make alot more sense to know what those opitmizations are
<daurnimator>
"it only optimizes what is worth optimizing" -> well yeah; what else did you expect?
<scientes>
i.e. 1) inlining, 2) profile branch prediction scheduling
<andrewrk>
scientes, PGO is an entirely separate thing
<scientes>
3) function splitting
<via>
andrewrk: yeah, but as i learned this morning i can't directly use libopencm3 in zig
<via>
yeah, i feel like you're confusing a bunch of things
<scientes>
there could also be a LTO register allocator
<scientes>
but there isn't
<scientes>
I am doing a project right now that could use that
<scientes>
where you unroll a outer loop into an inner loop to maximize OOO multi-issue
<scientes>
but that is quite specialist, so probably should just be done by hand
<daurnimator>
why does this make it scary/"not a very good idea"
<via>
i, and i think most others, use whole program optimization to just mean across object boundaries
<via>
which yeah, uses some extra info in object files which i guess is mostly compiler/linker specific
<scientes>
it might actually work quite well with zig
<scientes>
as zig would be doing all the compiling
<via>
it does dead code elimination, automatic inlining ... and at least in my project, produces pretty significant performance gains due to the lack of branching
<daurnimator>
via: so LTO with GCC works by adding GIMPLE bytecode to the objects
<scientes>
what is scary is when you take a stable ABI from a shared library, and suddenly don't actually use it
<daurnimator>
via: I would not expect GIMPLE in those objects to be useable by lld
<via>
yeah, i figured lld couldn't use it
<scientes>
because you are pretending that function is static and doesn't follow the C ABI anymore
<daurnimator>
via: but at the same time, I would have expected lld to be oblivious to them; and end up just not doing LTO. rather than a 0KB output
<via>
scientes: this is a static library i'm linking into a static freestanding executable
<via>
daurnimator: yeah, it does seem like a weird results, i expected that too
<scientes>
if its made to be static, I can see that you would want all the performance you could get
<daurnimator>
via: my first thought is that maybe lld doesn't know the entry point(s), and ended up garbage collecting *all* sectiond
<scientes>
and then it would make plenty sense
<daurnimator>
scientes: you're mixing *so* many concepts up here.
<scientes>
well I see the terms, but rarely do they actually describe the transforms
<via>
that was my thought too, that maybe i need to make sure that my entry point is kept -- i know if i were using lto just with libopencm3 and a bare c file with no entrypoint, everything would get eliminated as dead code
<via>
but since it own't work anyway, i'll just not use lto and see how bad the hit is nowadays
<scientes>
and they aren't concepts, C is a as-is language, so as long as the program runs as-is it is fine
<scientes>
the question is what ABI/APIs you implement
<daurnimator>
via: so first thing I'd so is to just swap to compile libopencm3 with clang instead of GCC
<via>
yeah, i can try that
<via>
though i need a clang arm cross compiler first
<daurnimator>
via: hint: zig is one
<scientes>
^^^^
<daurnimator>
via: `zig cc` <-- is built in clang cross compiler
<via>
can i just use CC='zig cc' with an existing makefile based c project?
<daurnimator>
yep
<scientes>
and it can build like 15 differn't architectures
<daurnimator>
though for a cross compiler you might need -target or similar
<scientes>
if it only supports gcc cross-compilers that is
<scientes>
you can just do CC="zig cc -target arm-non-eabi" however
<darithorn>
i found what was causing the issue. i had a recursive data structure
<via>
yeah, though now i need to figure out how to make clang build with hard float for this arch, and lto. which i can do, but i might call it a night and do it in the morning
<andrewrk>
`zig cc` won't provide libc and compiler_rt though. but you can use `zig build-exe --c-source [flags] foo.c` to do that
<andrewrk>
you probably want musleabihf
<via>
compiler-rt might be needed for a few things, and libopenc3 is pretty big, i don't know if i can build the whole project that way
<via>
why would i need to link in musl?
<via>
maybe i misunderstand
<andrewrk>
you don't but that will at least communicate that "hard float" is part of the target
<scientes>
via, that is the abi, you don't have to use a libc
<via>
oh, ok
<andrewrk>
libopenc3 will be a good candidate to port to the zig package manager. then it'll be real easy to cross compile using it, whether with C or Zig
<scientes>
(and if you don't the glibc and musl variants are the same)
<via>
one remaining piece of output t odeal with is this: /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
<via>
not sure why its using what looks like my system stdint.h
<via>
and yeah, maybe unobvious, but i'm a huge fan of libopencm3, and i really would love to move past C to something else for a lot of what i'm doing
johnLate has joined #zig
<scientes>
via, you actually probably want musleabi, i don't think that has a FPU
<via>
my chip has an fpu
<scientes>
oh, then musleabihf
<via>
and i use the crap out of it :p
<scientes>
do any of those have NEON?
<via>
don't think so, its just a cortex-m4f (stm32f407)
<andrewrk>
the package manager is still vaporware at the moment, but you could bundle libopenc3 source into your project and build it with zig build system. that will auto cache it, and cross compile it, and supply compiler_rt to it
<via>
project is a engine control system (ignition and fueling), fwiw, open source, currently in C, evaluating porting to zig
<scientes>
add they created Helium for doing SIMD on low-end chips
<very-mediocre>
I just found myself writing this abomination: std.debug.warn("-- {}\n", if (root_node.nodes) |nodes| if (nodes[1].symbol) |sym| ([_]u8{@intCast(u8, sym.val)}) else null else null);
kristoff_it has quit [Ping timeout: 245 seconds]
<very-mediocre>
would be much better if you could do `std.debug.warn("-- {}\n", if (root_node.nodes?[1].symbol?.val) |val| ([_]u8{@intCast(u8, val)})[0..] else null);`
<samtebbs>
very-mediocre: That's an interesting idea, what syntax would you propose?
<very-mediocre>
.? could be deprecated and you'd just do something like `someone?.something?.something_else?.value orelse unreachable`
<samtebbs>
Could do `something.!value` but that can be confused with the exclamation mark used in error returns
<very-mediocre>
admittedly it's not the same
<very-mediocre>
hmm
<samtebbs>
Does `null orelse unreachable` evaluate to `unreachable`? If so that would do the same thing
<very-mediocre>
same outcome but you lose granularity about which expression triggered the `orelse unreachable`
<very-mediocre>
eh, that's very narrow though, I would argue in favor of deprecating .? after all
<mikdusan>
or `a?.b?.value` for optional chainging, and `a!.b!.value` for unwrap chaining and deprecate `.?`
<very-mediocre>
I like that
<very-mediocre>
fyi. what I've been doing is sneaking in some spare time to write some serious zig code, and I keep feeling the lack of this pattern
<Flaminator>
Do you have many optionals in your code?
<very-mediocre>
yes
<very-mediocre>
situations like when you're dealing with nodes that may or may not have child nodes
<scientes>
C# has that (i've never used C#, just heard about that feature)
<mikdusan>
hmm mind for grammar right now error unions use `!` which might be a conflict. eg. tons of `Error!void` use in std so a suffix `!` for unwrap operator might have grammar conflicts
<scientes>
! is always exceptional
<scientes>
*also
<scientes>
I would like to keep the . in the syntax
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
<samtebbs>
mikdusan: That was my reservation too
<samtebbs>
`.&`?
<scientes>
ewww
<very-mediocre>
scientes? what benefit does the . provide?
<scientes>
& already has two uses (three in C)
<scientes>
its a method
<scientes>
it makes it clear it isn't part of the symbol
<very-mediocre>
(i accidentally just optional'd scientes' name)
<scientes>
in ruby its custom to use ? as part of symbols that return bool
<mikdusan>
so dumb question. why can't analysis figure `.*` to deref a pointer, and `.*` to unwrap ?
<scientes>
it can
<mikdusan>
and then that frees up .? for optional null check.
<scientes>
but it would require some re-writing which we already need to do element extraction from vectors vector[3]
<very-mediocre>
? as a suffix is currently an invalid character for a symbol anyway, I don't see the importance of the .
<scientes>
yeah but people learning the language don't know that
<very-mediocre>
likewise ! as a suffix isn't currently allowed, so it's distinct from error sets
<scientes>
actually its weird, because its actually a dereference
<scientes>
and you are taking the address
fengb has joined #zig
<mikdusan>
i like `.*` for deref/unwrap, and `?` for optional chaining, the latter esp because other langs have popularized it
<scientes>
yes, but with a .
<scientes>
.* and .?
<scientes>
which would make .* unsafe and .? safe
<very-mediocre>
mikdusan: + it works as a counterpart to ? prefix denoting an optional. The current ? prefix communicates you know in advance it can be null, while a hypothetical ? suffix communicates a query about whether it's null
<scientes>
oh yes the consistancy is nice
<mikdusan>
very-mediocre: yeah if given choice `?` more of a null query to me, than an unwrap operation
<very-mediocre>
it's a query with an implied "orelse (entire expression) is null"
<scientes>
but the difference between .* and .? is similar to . and -> in C and most languges have dropped that because in most code you don't give a shit which is which
<very-mediocre>
I like -> because I like to remember I'm using a pointer
<scientes>
(and now C++ has that with references)
<scientes>
yeah but with zig pointers they are both safe
<scientes>
and c++ reference are the same thing
<scientes>
i prefer without c++ because i spend so much time recompining my code to fix them all
<scientes>
but yeah it does make the data structure a little clearer
<very-mediocre>
I think it isn't inconsistent to have .* and ? (without the .), the former is accesses something through an indirection, while the latter doesn't represent an access
<scientes>
scala does it with the .
<scientes>
val name = article.?.author.?.name : @ ?
<scientes>
oh its a library
<Flaminator>
Imo having to get null in a round about way is a good thing.
<scientes>
yeah, what if you want to do a differen't thing with null at each level of dereference?
<scientes>
this sort of thing is only common is certain specific situations
<very-mediocre>
then you can always use the verbose status-quo style
<mikdusan>
scientes: sure, json and petty much anything with recursive maps benefits from optional chaining
<mq32>
scientes: I only know the "?." operator from C#, but i used it a whole lot of times
<mq32>
most common use case in c# was something like
<mq32>
var x = obj?.a ?? sane_default;
<mq32>
where ?? is the equivalent to the "orelse" operator of Zig
<scientes>
we use that have ??
<scientes>
orelse is better
<mq32>
i'm also a fan of more verbose operators
<scientes>
Like perl is almost incomprehensible if you aren't familiar with it
<mq32>
i'm even using "and" "or" and "not" in C++
<scientes>
using English when the English is clear is good
<scientes>
mq32, with a macro?
<mq32>
nah, it's actually builtin!
<Flaminator>
Pretty sure and or and not are build in.
<mq32>
C++ has the iso646 operator set builtin
<scientes>
oh weird
<scientes>
do you have to use some header for that?
<mq32>
Flaminator: it is. But not in Microsoft C++ except you have a "PLEASE CONFORM WITH STANDARD" compiler flag set
<mq32>
nope
<very-mediocre>
re:verbosity: for that reason .? can be replaced with `orelse unreachable`, if anything this kind of assertion-ish scenario might be too important to use a shorthand
<Flaminator>
I think most operators have an alternative. xor/or/and and their _eq brothers.
<scientes>
so if it isn't available in C I am not really itnerested
<scientes>
oh cool it is
<scientes>
yeah i'll probably use that then
<scientes>
oh yeah I think dpkg uses that
redj has quit [Ping timeout: 245 seconds]
<mq32>
has somebody already made a request to change && || and ^ in Zig to the literal versions?
<Flaminator>
Pretty sure && and || are not valid operators.
<fengb>
|| is error set merges. && is invalid atm
<mq32>
ah wait
<scientes>
no, the binary operators are much rarer than the bool operators
<mq32>
i messed up, Zig has "and" and "or", but no "not", instead it has the C version
<scientes>
so I think they should stay same as C
<scientes>
but that is my opinion
<mq32>
sorry 'bout that
<scientes>
but yeah && and || in C are ugly
<mq32>
but on the topic of the syntax of the safe navigation stuff:
<mq32>
i prefer the "?." syntax over ".?" because it reads more "logical" (in terms of "left to right")
<fengb>
I prefer `.x` because it seems to be a decent standard for postfix operators
<scientes>
ekkk, use a valid symbol?
<scientes>
I think that is a bad idea
<very-mediocre>
.* is an indirection, it evaluates to what the pointer points to (access operation). The proposed ? does not evaluate to the result of accessing an indirection, so the . seems unintuitive.
<very-mediocre>
something? evaluates to something or null, not the "contents of" something
<fengb>
Contents of null unwrap
<very-mediocre>
in the chain example the unwrapped value doesn't get exposed
<samtebbs>
very-mediocre: But having `something?` by itself makes no sense
<samtebbs>
it expands to `if (something == null) null else something`
<samtebbs>
Which is just `something`
<very-mediocre>
Zig doesn't let you use an optional for safety reasons
<samtebbs>
It only make sense when you're accessing the contents of that something, hence why you'd need to add the `.`
<very-mediocre>
ok, sure, but the main point is chaining
<very-mediocre>
i see your reasoning wrt. it being an access
<very-mediocre>
but it's still not quite an unwrap
<very-mediocre>
something.? might be null, i wouldn't call that an unwrap
<very-mediocre>
or rather i wouldn't call that a `capture` if we're going to be accurate
<very-mediocre>
so it wouldn't be an access
<very-mediocre>
ahh, too theoretical.
<samtebbs>
Yeah the only way to unwrap that I've encountered is `if (something) |something_unwrapped|`
kristoff_it has joined #zig
nifker has joined #zig
<very-mediocre>
I think the theory is futile, there's no objective answer. I find it intuitive to read `something?` in a certain way, I guess other people find `something.?` more intuitive. Either way I think that's ultimately moot. :)
<fengb>
I'm just offering consistent postfix syntax >_>
<very-mediocre>
I understand, but it depends on how you read it. I don't read it as a "true" indirection the same way a pointer dereference is/
<fengb>
.* was added for disambiguity, not necessarily for access
<very-mediocre>
anyway the . discussion is premature, the question is, do you folks think this is worth a proposal?
<fengb>
Of course... we don't have a ? infix operator but I would kinda like all postfix operators to have the same parsing technique
<mikdusan>
very-mediocre: i think we need an optional chaining solution. yes.
<very-mediocre>
fengb: Maybe controversial, but I don't think "postfix" is a general concept that the language design ought to conform to.
ntgg has quit [Ping timeout: 244 seconds]
<fengb>
I don't understand what you mean. foo? is a postfix operator already
<very-mediocre>
you say postfix, I say access operator (tomato, tom-ah-to)
<fengb>
The ? is postfix by parsing
<very-mediocre>
Yes it's a suffix, but I don't see that as a useful way of categorizing things
<very-mediocre>
and i don't see consistency in that regard as a goal, insofar as .* would require .? and not ?.
<fengb>
Language grammar should be simple... and Zig has made many decisions to err on simplicity
<mq32>
fengb, i think very-mediocre thinks of "postfix operator" in terms of usage, not grammar: "i++" would be postfix, "i.j" would be infix/access
<fengb>
Infix is i * j
<samtebbs>
Postfix is just the position in the parsing term, nothing to do with semantics
<mikdusan>
waat i thought you guys were talking about an email server this whole time
<very-mediocre>
it's too theoretical if you ask me
<samtebbs>
very-mediocre: But yeah open up a proposal and let's have this discssion in an issue, where it can be formatted and recorded nicely
<very-mediocre>
imho the final outcome is what counts most, except if it's prohibitive to implement in the parser
<very-mediocre>
I'll do a short writeup soon and float both syntax options
<Flaminator>
I atleast think it's best to have it something like ".{sign}" like it is now with ".*" and ".?".
<very-mediocre>
this . seems quite divisive :)
<very-mediocre>
reminds me of several months back when .{.member=1} was in a proposal
<very-mediocre>
i dub that the nipple operator
<very-mediocre>
(not a fan)
<fengb>
Not a fan of nipples?
<very-mediocre>
not in programming languages :)
<samtebbs>
lel
<scientes>
nipple operator
<very-mediocre>
I was more focused on the chainable optionals operator, I didn't note any consensus on an unwrapping operator, shall I just leave that out?
<mq32>
what would be the unwrapping operator? "ignore that this optional may be null and just do what i say?"
<fengb>
Oh we already have the `.?` operator
<fengb>
`a.?` equivalent to `a orelse unreachable`
<Flaminator>
Yes the .? operator is basicly value orelse unreachable.
<very-mediocre>
it would be deprecated, and mostly replaced by `something?.value orelse unreachable`
<very-mediocre>
and imho i prefer a more verbose "orelse unreachable" than a shorthand for it, but that's just me
<very-mediocre>
mq32: good question, I've thought of it a certain way but I'm not sure I'm aligned with what mikdusan was talking about
<mikdusan>
i was suggesting that since we already have `.*` to deref pointer and that's likely not going anywhere,
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
<mikdusan>
that compiler could be enhanced to allow `.*` to be used _also_ for what is currently done by `.?` (unwrap optional)
<very-mediocre>
I assumed it would work on errors -> `catch unreachable`
<mikdusan>
thus freeing up `.?` in the case that is used for optional chaining. or in the case just `?` is used for optional chaining, removing `.?` for unwrap makes things clearer
nifker has quit [Ping timeout: 272 seconds]
nifker has joined #zig
Tetralux has quit [Ping timeout: 258 seconds]
Tetralux has joined #zig
<kristoff_it>
Hi all, I posted https://github.com/ziglang/zig/issues/2814 to ask for some resources/pointers on writing network clients in Zig. Does anyone here have any articles/papers/books/videos/koans to share on the subject?
<kristoff_it>
I have very dumb questions in my mind such as "are streaming parsers worth it if you have to call the function on every single input character?" or "will I incur in any bad performance problem if I set off trying to keep the parsing logic completely separate from the networking code?"
<Tetralux>
I don't quite know what you mean by "called on every character" -- you'd probably more take a slice of bytes---a 'chunk' of newly read data from the stream, and then process it as much as you can.
<Tetralux>
You wouldn't call it on a per character basis.
<Tetralux>
You'd call it on a per-chunk basis.
<Tetralux>
But maybe I'm missing some nuance here.
very-mediocre has quit [Read error: Connection reset by peer]
<via>
though even if i just have one call to toggle_blink, zig doesn't seem to want to inline it even with release-fast, but meh, this is still pretty great
ntgg has quit [Quit: leaving]
<andrewrk>
kristoff_it, I think those are good questions, and even experts in this community would need to write code and benchmark it to find out the answers
<kristoff_it>
very-mediocre: thanks I'll check the link out
<kristoff_it>
andrewrk: thanks, I imagine getting everything precisely right is non-trivial and probably use-case specific, I'm mostly interested in common practices so that I don't endup rediscovering fire after burning myself multiple tiems
<andrewrk>
streaming where possible is certainly common practice
Akuli has joined #zig
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
nifker has quit [Ping timeout: 258 seconds]
hio has quit [Quit: Connection closed for inactivity]
redj has joined #zig
very-mediocre has quit [Read error: Connection reset by peer]
wootehfoot has joined #zig
samtebbs has quit [Quit: leaving]
avoidr has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
<marler8997_>
Why are function parameters always const?
<hryx>
marler8997_: I asked that once in an issue and got a good response, let me find the link for you
<marler8997_>
> If you need a mutable parameter, var foo = param; is an easy, reasonable way to get it, that comes at no performance cost.
<marler8997_>
no performance cost?
<andrewrk>
if zig were to introduce mutable parameters, it would have to secretly generate `var foo = param;` to make them work
<marler8997_>
is that an LLVM-ism?
nifker has joined #zig
<marler8997_>
does that result in 2 copies? one copy from the caller and one copy inside the call?
<andrewrk>
for scalar types such as integers and floats, the concept of a "copy" doesn't make sense
<marler8997_>
one MOV from the caller to the function frame, and one MOV from the function frame to a local variable
<scientes>
frame?
<scientes>
you usually pass in variables
<scientes>
*pass in registers
kristoff_it has quit [Ping timeout: 246 seconds]
<marler8997_>
depends on the ABI, but the question still applies
<marler8997_>
why force the user to have to move the data twice?
<scientes>
marler8997_, LLVM is SSA
<scientes>
so it doesn't know what variables even are
<scientes>
so as andrew says, it doesn't really a concept of copying them
<andrewrk>
there's no data being moved twice, unless you actually want a copy of an aggregate type. if you don't want a copy of an aggregate type, don't make a copy
<marler8997_>
I am using an aggregate type
hspak has quit [Ping timeout: 245 seconds]
hio has joined #zig
<andrewrk>
then pass it as immutable, in which case there is no copy, or pass a mutable pointer if you want to mutate it
<marler8997_>
I need to be able to modify it
<marler8997_>
but I don't want to modify the caller's copy
<andrewrk>
so you want a copy
<andrewrk>
make a copy
<marler8997_>
but isn't the parameter already a copy?
<scientes>
your debug statements will change the behavior of a function like that
<marler8997_>
because I'm taking the address of the data?
<scientes>
yeah if you turn on optimizations it inlins the function
kristoff_it has joined #zig
<andrewrk>
marler8997_'s example shows pointer addresses to show whether or not copies occur and it's notable whether they happen in debug builds
<scientes>
so clearly the answer is just "you need to turn on optimizations if you are going to complain about optimization problems"
<scientes>
oh i see
<andrewrk>
scientes is incorrectly assuming that we want to look at optimized release builds for this example
<marler8997_>
not complaining about optimization, I'm asking why parameters are alwayas immutable
<marler8997_>
it sounds like the reason is because parameters aren't necessarily a copy
<marler8997_>
I'm just use to C, so this is very different
<scientes>
the static analyzer could still figure that out, even in C. But I think it prevents a footgun , you can always just copy out of the parameter
<andrewrk>
marler8997_, you can use e.g. "{*}" and `&tpInMain` and it will print pointer format
<andrewrk>
this backs up what I said earlier: the only copy is the one you make
<marler8997_>
yeah
<andrewrk>
for C ABI functions, one would have to rely on the optimizer to elide the copy
<marler8997_>
are extern C function parameters also forced const?
kristoff_it has quit [Ping timeout: 245 seconds]
<andrewrk>
yes
<scientes>
It means that you can always access the parameters that were passed
<marler8997_>
hmmm, I think ideally those would be treated differently
<scientes>
which eliminates stress for the programmer
<marler8997_>
but probably not a big deal
<marler8997_>
since it would be fairly rare
<scientes>
what I do if I want to change it is call the parameter _foo, and then assign it to foo
<scientes>
auto with auto typing it works pretty well
<marler8997_>
one thing that's confusing is that the type of the parameter looks mutable even though it's const
<marler8997_>
what if you required the function to declare it as const?
<scientes>
just set it const
Ichorio has joined #zig
<marler8997_>
sure, but what about the use case I talked about. It's still const even if you don't include const
<scientes>
no it isn't
<scientes>
because you can assign it to a var
<scientes>
oh wait, that isn't right
<andrewrk>
marler8997_, it's consistent with all the other capture variables
<andrewrk>
for (array) |item, i| {}
<marler8997_>
that one doesn't have a type
<scientes>
everything has a type
<mikdusan>
he means lexically
<marler8997_>
it doesn't have an explicit type like a function does
<scientes>
oh yes
<scientes>
the point is that you can always use the parameters as they were passed, those never get shadowed
<andrewrk>
that's correct, currently true everywhere
<marler8997_>
that's irrelevant to my point, I'm talking about putting const on the parameter type now
<marler8997_>
not making the parameter mutable
<scientes>
it has an effect if it is a slice or pointer to const data
<marler8997_>
hmmmm, I'm still learning these new semantics, you can't specify (const u8) in a function parameter
<marler8997_>
so you can't even do what I'm proposing anyway
<marler8997_>
D handles const completely differenty. It's always a type modifier. Whereas in zig, it's a type-modifier when you're talking about pointers and arrays, but it's also associated with other things such as whether it's a parameter/loop variable
<marler8997_>
I should say "head const" is handled differently
<scientes>
thats because there is "var" and "const"
<marler8997_>
well D has that too, but it modifies the type
<marler8997_>
const foo = 0; (typeof foo is (const int))
<scientes>
actually const comptime_int
<marler8997_>
in zig, it doesn't modify the type
<marler8997_>
that example was in D, not Zig
<andrewrk>
`const int` doesn't make sense, but `*const int` does
<marler8997_>
can you elaborate on that one andrew?
<andrewrk>
mutability describes locations, not types
<marler8997_>
sure, but the type could reflect the mutability of it's location as well
<andrewrk>
it doesn't make sense that a type knows its location
<marler8997_>
why not?
<marler8997_>
if you think about it, you can put any information you want into a type, of course whether or not you should is another question
<marler8997_>
you could have the type know it's location, who owns it, whether it's a pointer that ends with a null value, etc
<hryx>
if type information were to include location, wouldn't every single variable have a different type?
<marler8997_>
yeah that would be the extreme side of it, that each value has it's own type
<marler8997_>
but we weren't saying it would include it's location, just that it's location could modify the type
<marler8997_>
andrew doesn't think that makes sense and I'd like to understand why that is
<marler8997_>
it looks like in Zig, head-const is determine by the variables location, and tail-const is stored in the type
kristoff_it has joined #zig
<marler8997_>
I'm not sure whether that's a good or bad choice, just trying to understand the reasoning
kristoff_it has quit [Ping timeout: 245 seconds]
<mikdusan>
is `zig --help` missing text for `--override-lib-dir` to limit help noise, or is it bonafide oops missing?
<andrewrk>
oops missing
wilsonk has quit [Ping timeout: 272 seconds]
<marler8997_>
I'm thinking about the consequences of not including head-const in the type, one use case that comes up is struct members
<marler8997_>
is there a way in zig to declare a struct member as head-const?
<andrewrk>
there is not
very-mediocre has quit [Read error: Connection reset by peer]
<marler8997_>
any research/discussion on that?
<marler8997_>
I've read that making things "const" reduces strain on the developer and the argument has been used for other features
very-mediocre has joined #zig
<andrewrk>
I'm not aware of any open issues
<marler8997_>
from what I'm gathering at the moment, whether or not a type is head-const can usually be inferred from it's location, so including it in the type would be redundant
<marler8997_>
however, in the case of struct members, since there's not way currently to declare a member as head-const, the type could be used in this case to declare whether or not it's head const
<marler8997_>
but of course, there could be other ways, just saying that this is a case where having it in the type would not be redundant
<very-mediocre>
hryx: re: proposed ? suffix in #2816 -> it rhymes with the existing ? prefix that defines optionals in the first place [https://youtu.be/yFqFLo_bYq0?t=15]
<very-mediocre>
erroneous ] at the end of that url
kristoff_it has joined #zig
<hryx>
if George Lucas says it's a good idea then it must be. case closed!
<marler8997_>
still thinking on this...if we look at the function parameter case, head-const could be used to make parameters mutable/const without needing copy the parameter into a local variable. The compiler would essentially generate the "var fooVar = fooParam" when the parameter is declared as mutable
<marler8997_>
So in that case, head-const and non-head-const parameters would have different semantic meaning, thus not redundant in that case either
kristoff_it has quit [Ping timeout: 258 seconds]
jjido has joined #zig
<very-mediocre>
has anyone here worked on deflate? I'd be interested in sharing notes
wilsonk__ has joined #zig
kristoff_it has joined #zig
<hryx>
very-mediocre: is your deflate project on github? you should totally link to it from one of the issues
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
<andrewrk>
emekankurumeh[m]: I changed Builder to get heap allocated
kristoff_it has joined #zig
Ichorio has quit [Ping timeout: 252 seconds]
<marler8997_>
just ran my "downloadlatest" script and noticed there was a new update....are updates to ziglan.org/download automatically pushed once a day or are they manual or both?
<mikdusan>
every ci build
<emekankurumeh[m]>
it's part of the ci script
<marler8997_>
ah thanks
<emekankurumeh[m]>
when it passes successfully after a merge
<nifker>
why am I not allowed to use tabs in zig source code?
<mikdusan>
when is zig going to support `var a = 10 ÷ 4;` :)
<hryx>
gahaha
samtebbs has quit [Ping timeout: 260 seconds]
kristoff_it has quit [Ping timeout: 248 seconds]
<marler8997_>
well that was an interesting 15 minutest reading through the whitespace discussion. It surprises me how passionate people get about such trivial things
<emekankurumeh[m]>
andrewrk: i'm writing some blocking networking stuff for the stdlib, is it okay if i break std/event/*?
samtebbs has joined #zig
<Flaminator>
Yeah the whitespace preference(tabs vs spaces and \r\n vs \n) is something that will never really get solved if a language doesn't force something and allows both.
<marler8997_>
I think the discussion is fine, but I don't like seeing people get so riled up. I don't know why but us humans can get very passionate about things that really don't matter. Wish I knew why.
very-mediocre has left #zig [#zig]
<Flaminator>
And that is the reason why, people have different things they think that matter and things that don't matter.
<hryx>
twitch stream today?
<Flaminator>
andrewrk will there be any twitch streams today?
kristoff_it has joined #zig
<andrewrk>
ah, yes I'm planning on doing that. wow it is almost 5pm already
<andrewrk>
damn was hoping to finish up this patch
<andrewrk>
I'll do a stream in 1hr10min
<andrewrk>
I don't even know what timezone I live in anymore. I've been saying EST but I found out yesterday that is off by one hour
<scientes>
lol
<hryx>
daylight savings? wobbly earth orbit?
<scientes>
lots of leap seconds
<Flaminator>
That is why I never use CET(current CEST because of daylight saving time) but always just use UTC+01:00/UTC+02:00.
<andrewrk>
apparently your time zone changes, when daylight savings time happens. rather than your timezone adjusting its time
<samtebbs>
I've tried using types_match_const_cast_only on wanted_type.data.pointer.child_type and actual_type.data.pointer.child_type but they don't seem to match
<andrewrk>
you're on the right track
<samtebbs>
Ok :)
<samtebbs>
Am I using the right function and variables?
<andrewrk>
I'm not sure, I can take a look after the stream
<samtebbs>
Thanks, I'll probably be asleep by then but will check tomorrow!
<hryx>
while waiting for eyes on the translate-c PR I'm starting on #2129 (support for u{xxx} characters)
<hryx>
seems like a reasonably small-scoped project
cheesy has quit [Quit: zzz]
<hryx>
oh no, looks like zig test doesn't operate on a directory?
<andrewrk>
hryx, that's one of the consequences of lazy analysis
<hryx>
oh I see -- is it related to needing to specify a single root file?
kristoff_it has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<scientes>
hryx, are you working from my work on #2129?
<hryx>
BTW I have come to appreciate and enjoy the root file concept and its consequences. originally I didn't get it but I like it now
<scientes>
I think my work was pretty good, and should be a good starting point
<scientes>
but it is a bit disorganized
fengb has joined #zig
<hryx>
scientes: I'm not - are there gotchas I should be looking out for?
<scientes>
hryx, perhaps I should just take some time and get my patch ready for re-submission
<scientes>
or rather patch series, as there are many parts to that bug
avoidr has quit [Quit: leaving]
<hryx>
andrewrk: boy do I love seeing some red in diffs
<scientes>
nice feature too
<andrewrk>
scientes, nice, I'd look forward to some of your older patches that I closed, but you know, submitted in a way that makes it easier for me to merge
<hryx>
scientes: I know you put some work into it and I don't wanna step on your toes. but do let me know if you intend to resubmit so that I can more properly direct my energy
<scientes>
well that is why I feel I sound take the time
<andrewrk>
hmm, considering experimenting with playing some chill music during this stream
<scientes>
because your time could be better spent on other things
<scientes>
andrewrk, and you were right for closing them
cheesy has joined #zig
<andrewrk>
I didn't like doing it though, it feels bad to reject people's code
<scientes>
that is your job
<hryx>
andrewrk: let me know if you need recommendations for creepy ambient music. unless you didn't mean THAT chill
<scientes>
or rather, role
<scientes>
Grek Kroah Hartman has spoken about this quite a bit
<scientes>
and gives good advice
<andrewrk>
streaming now
<hryx>
scientes: your original patch looks good, why didn't you just remove all the stuff that doesn't have to do with #2129? Things like unicode validation, the #2097 fixes, etc.
<scientes>
well they do kind all belong together
<scientes>
i plan to submit them as a patch SERIES
<scientes>
but plenty of that stuff does not
marijnfs_ has quit [Ping timeout: 268 seconds]
kristoff_it has joined #zig
marijnfs_ has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
darithorn has joined #zig
kristoff_it has joined #zig
brakmic has quit []
<emekankurumeh[m]>
does zig fmt strip excess whitespace?
marijnfs_ has quit [Ping timeout: 245 seconds]
kristoff_it has quit [Ping timeout: 245 seconds]
<hryx>
emekankurumeh[m]: it should do so already, yeah
<marler8997_>
So is [*c]u8 supposed to be the latest version of [*]null u8?
<fengb>
No, [*c] means ambiguous whether it's * or [*]
<fengb>
We don't have [*]null yet
<marler8997_>
oh...interesting
<hryx>
marler8997_: [*c] should only be generated from translate-c, not written by hand
<fengb>
It's mostly for translating C because all pointers are kinda arrays
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
<samtebbs>
andrewrk: I figured the casting thing out in the end, I just had to add to one of the checks already there
samtebbs has quit [Quit: leaving]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
hio has quit [Quit: Connection closed for inactivity]