<mikdusan>
maybe add this to ci script at beginning: system_profiler SPHardwareDataType
<_Vi>
What does man in Zig, when in C one passes a function pointer and `void* usrarg`? I.e. how callbacks work in Zig?
<_Vi>
Shall it be like in C (passing some `usize` or equivalent value down) or like in Rust (making the entire thing genetic, accepting type T for callback function argument type)?
<_Vi>
*generic
<_Vi>
Looks like generic approach (`fn do_things(usrdata: var, callback: fn(usrdata: @typeOf(usrdata), x))`) works.
<_Vi>
Where is this "var" in `fn(arg: var)` context formally described?
<_Vi>
I see it used in snippets in the documentation, but not explained.
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
scientes has joined #zig
<andrewrk>
_Vi, good point, I don't think it's formally documented
<andrewrk>
it is stable though
<andrewrk>
mikdusan, done
<mikdusan>
azure why don't you let me view the beginning of an in-progress log? (yes i clocked off follow-tail)
<andrewrk>
I missed it too
<andrewrk>
it shows the whole log after it's done
<mikdusan>
i'm just going to bet 4GB VM
<andrewrk>
agreed
<andrewrk>
I'll leave this diagnostic on for now
<andrewrk>
maybe it's some kind of vm overcommit thing though
stratact has quit [Remote host closed the connection]
stratact has joined #zig
<andrewrk>
ok I apologize for this but I'm going to `mv std/ lib/` now
<mikdusan>
so WORKTREE/lib/ == INSTALL/lib/zig/
<andrewrk>
yes
<andrewrk>
--override-std-dir gets deleted. it's just --override-lib-dir now
<mikdusan>
Memory: 12 GB
<mikdusan>
what
<mikdusan>
overcommit. alert. lol
<andrewrk>
hmm I do think this is evidence in favor of my hypothesis
<mikdusan>
i think only real info there is #cpu_packages, #cpu_clock #cpu_cache_sizes; my guess: Intel® Xeon® Processor W3680 MacPro5,1 (2010)
batok has quit [Ping timeout: 276 seconds]
chemist69 has quit [Ping timeout: 245 seconds]
chemist69 has joined #zig
doesntgolf has quit [Ping timeout: 240 seconds]
<andrewrk>
damn, cmake doesn't have a way to add a custom target to `make install`. that's a pretty glaring deficiency
mahmudov has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
<andrewrk>
Sahnvour, I think you will appreciate the new -DZIG_SKIP_INSTALL_LIB_FILES option
<andrewrk>
in summary: enable the option and no lib files are copied on `make`. rm -rf your lib/ folder in your build directory and zig will pick up the one from the source directory
mahmudov has joined #zig
ltriant has quit [Quit: leaving]
mahmudov has quit [Ping timeout: 268 seconds]
MajorLag has joined #zig
tgschultz has quit [Ping timeout: 246 seconds]
MajorLag is now known as tgschultz
letoram has joined #zig
mahmudov has joined #zig
<marijnfs__>
no zig update:(
<marijnfs__>
working on something cool?
mahmudov has quit [Ping timeout: 245 seconds]
avoidr has quit [Quit: leaving]
mahmudov has joined #zig
mahmudov has quit [Ping timeout: 265 seconds]
mahmudov has joined #zig
SyrupThinker has joined #zig
mahmudov has quit [Ping timeout: 245 seconds]
<_Vi>
Is taking `var`-typed argument "x" equivalent to taking `comptime xType : type, x : xType` where xType auto-fills with @typeOf(x) at call site?
<mq32>
_Vi: yes
<_Vi>
How string is Zig's `translate-c`? Can it, for example, translate OpenSSL?
<_Vi>
*strong
<ceymard>
I think I'm onto something for the completion
<ceymard>
say, do functions have properties ?
<ceymard>
like slices and arrays have .len
slice has quit [Ping timeout: 265 seconds]
<mq32>
ceymard, afaik noot
<mq32>
_Vi, it can translate (in theory) everything that is not "macro magic"
<mq32>
so simple macros will work, but more complex macros will not
<_Vi>
mq32, Can it just expand macro magic and translate the result?
<mq32>
nah, that wouldn't work
<mq32>
because macros emit C code and are not "inline functions"
rifkik has joined #zig
slice has joined #zig
batok has joined #zig
<fengb>
marijnfs__: andrewrk is preparing the scheduled release so all documentation all day
<_Vi>
Maybe `struct qqq{};` can be a sugar for `const qqq = struct{};` then? (and so on for enums and unions).
<mq32>
nah, with #1717 even the support for "fn foo() { }" will be dropped
<_Vi>
Does handling of leading `fn`, `struct`, `union` and `enum` complicates parsing or language grammar?
<_Vi>
I think immediately assigning newly defined something to a const is popular enough case to grant some syntax sugar.
<_Vi>
Or does `var self_modifying_function = fn () void { ... }` have real meaning, so `const` or `var` choice should always be explicit?
<_Vi>
If all types are immutable and cannot ever be `var`, then specifying `const`keyword every time seems redundant.
<_Vi>
Otherwise Zig code would be recognized from afar by constant usage of `const`.
<mq32>
const usage = const;
<fengb>
We could rename all keywords to variations of const!
<rifkik>
I have a question, about #1717
<rifkik>
Does it make it better?
<_Vi>
If `const` is intended to be used all the time then it should be abbreviated even more: `cnst` or even `c`.
<rifkik>
if it does, then why?
<fengb>
More consistent grammar and a way to do anon functions
<_Vi>
rifkik, 1717 brings uniformity between functions and other items.
<fengb>
Like assigning a function directly into struct fields isn’t possible atm
<rifkik>
Ah
<rifkik>
I isee
<rifkik>
And it's planned for 0.6?
<fengb>
Looks like it
<_Vi>
rifkik, Don't trust Github issue milestones, they tend to be pushed all the time.
<rifkik>
Oh, Okay
<ceymard>
when displaying the symbols of a zig file, what would you want to see ? anything declared (const / var / fn), even in function scopes ? or everything minus function variables ?
<ceymard>
also, would you rather see <just the name of the symbol>, or <parent>.<parent>.symbol in the list that is displayed ?
<ceymard>
(I'm talking about editing in vscode)
<mq32>
ceymard, good question
<mq32>
probably stuff filtered by imports
<mq32>
so if i type "std. " only the stuff that is contained in stf
<mq32>
rifkik: anonymous functions are a great gain of #1717: "sortSliceBy(mySlice, fn(a:*Item,b*Item) bool { return a.value < b.value; });"
_Vi has quit [Ping timeout: 246 seconds]
<ceymard>
mq32: this is completion stuff
<ceymard>
I'm talking about "all file symbols"
<ceymard>
which I already have working (because it's a lot easier)
<ceymard>
completion is a WIP
<ceymard>
I only have completion working at the scope level
<ceymard>
since I'm using a custom-built parser, I have to actually process types
<ceymard>
which I don't intend on doing very "seriously" at first
<ceymard>
so that we could complete some stuff albeit not completely correctly
<mq32>
ceymard, yeah i know. but i think you can filter for const foo = @import("bla"); and then search those files as well *grin*
<mq32>
that would be helpful
<ceymard>
that's planned
<ceymard>
since this is exactly what I needed in the first place :)
<ceymard>
I also plan to handle somewhat @cImport
<ceymard>
since I can run zig cc
<ceymard>
zig cimport sorry
<ceymard>
that and the builtin types also
_Vi has joined #zig
waleee-cl has joined #zig
<andrewrk>
marijnfs__, I am planning on streaming today
<marijnfs__>
andrewrk: awesome
<andrewrk>
not sure the topic yet
rifkik has quit [Ping timeout: 245 seconds]
<ceymard>
mq32: I'm starting to get auto complete from imports, but it's still quite raw
<ceymard>
well from variables too for that matter
<ceymard>
but there's still some to be done before actually calling this an "alpha"
<ceymard>
the progress is good though
lunamn_ has joined #zig
avoidr has joined #zig
lunamn has quit [Ping timeout: 240 seconds]
<andrewrk>
I think the stream topic today will be status update & demo of how to debug non-native architectures with qemu
<Tetralux>
It's worth knowing that qemu seems to work differently on Windows.
<Tetralux>
I can't seem to just `qemu-system-riscv64 program` for example.
<andrewrk>
I don't think usermode qemu is available on windows, just whole system emulation
<andrewrk>
well it makes sense. usermode qemu is very linux specific
<Tetralux>
That's not an OS limitation though is it@?
<andrewrk>
it might be
TheLemonMan has joined #zig
<andrewrk>
linux has some neat syscalls that let you do tricks like usermode qemu
<TheLemonMan>
usermode emulation means that the syscalls are just relayed to the host kernel, that's a bit hard to do on windows
<Tetralux>
Hmmm.
<Tetralux>
Sounds like a wine-like thing is required.
<TheLemonMan>
a liquor?
<Tetralux>
That took me second.
<_Vi>
What is code style for enum variants? E.g. in std/io.zig I see: `pub const Mode = enum { blocking, evented}; pub const Packing = enum {Byte,Bit};`
<mikdusan>
is combining case(s) with `else` in a switch supposed to work? `switch (thing) { .one, else => {...} }`
<andrewrk>
mikdusan, nope
<_Vi>
Is there some mark for unimplemented code in Zig? It should be like `unreachable`, but never cause UB in release mode, only safe abort or panic. May fail compilation although.
<andrewrk>
@panic("unimplemented")
<_Vi>
OK, but long-ish. Can there be `@todo()`?
<andrewrk>
no
<andrewrk>
we have to keep the language small
<andrewrk>
zig code will never be elegant
<andrewrk>
but can be maintainable and correct
* Tetralux
raises eyebrows
<Tetralux>
I'm always slightly uncomfortable when you say "never be elegant" xD
<Tetralux>
Always sounds like an anti-pattern.
<_Vi>
What is elegance in context of programming languages?
<andrewrk>
_Vi, appealing in a visual sense
<andrewrk>
terse
<TheLemonMan>
yeah, `usingnamespace` is such a eyesore
<andrewrk>
I tweaked that on purpose to get people to use it only when it's semantically needed
<andrewrk>
actually pretty happy with how that ended up
<andrewrk>
just wait for thisfileisautotranslatedfromc
<Tetralux>
So long as that has underscores x)
<TheLemonMan>
hah, you're taking the whole thing a bit too far IMO
<TheLemonMan>
I love me some usingnamespace + struct for grouping stuff
<andrewrk>
yeah that's a good use case
<andrewrk>
organizing APIs is the intended use of it
<TheLemonMan>
I can't see any other way to (ab)use it
<andrewrk>
can cause a compile error if third_party_package_1 gets an update and adds a function
<andrewrk>
even if that doesn't happen it's now more annoying to read code because any given symbol could come from 2 places
<TheLemonMan>
ehh, annoying to type names won't stop people from doing that
<andrewrk>
I'm not so sure about that. I've noticed many people use `var` instead of `const` even when the latter would be better
<fengb>
But it does look less idiomatic so beginners hopefully do a double take
<mikdusan>
with great power comes great responsibility
<Tetralux>
andrewrk: Random thought, why did you go with qualifier-oriented declaration syntax and not something else - like name-oriented syntax, for example.
<andrewrk>
I started with an existing language and morphed it into zig, I didn't invent zig from scratch
<andrewrk>
metaphorically
<Tetralux>
Oh interesting.
<andrewrk>
zig is C with the problems fixed. one of the problems of C is fixed by rust/go which is the var decl syntax
<Tetralux>
Did you essentially just say "Rust/go decl syntax is easier to read than C's - I'll use that" or did you evaluate several different kinds?
<andrewrk>
the former, but not easier to read, it actually solves a parsing ambiguity problem
<andrewrk>
I mean that also makes it easier to read, obviously
<companion_cube>
also goes better with optional type inference
<andrewrk>
yeah. zig benefitted a lot from copying existing good patterns of modern languages, without me fully understanding why (until years of work later)
<Tetralux>
companion_cube: Can you show an example of that?
<companion_cube>
`var x = 42;` vs `var x : i32 = 42;`
<companion_cube>
the structure is the same, you just have an optional type annotation
<companion_cube>
(same in rust ofc)
<Tetralux>
companion_cube: I see; named-oriented does that better IMO though.
<companion_cube>
contrast with the super weird `auto` of C++
<andrewrk>
same goes with LLVM. it's "training wheels". the backend I would have written 4 years ago if I didn't use LLVM would have been poor compared to if I started such a project today
<Tetralux>
x := 42; x : i32 = 42;
<companion_cube>
ughhhhhhhhh
<Tetralux>
(note the sigils are the same)
<companion_cube>
I hate this so much
* Tetralux
grins
<companion_cube>
so easy to miss the declaration of a new variable
<fengb>
There’s more parsing ambiguity
<companion_cube>
also it doesn't work with patterns, or makes parsing much harder
<companion_cube>
`(x,y) := …` yuck
<andrewrk>
also which one is which? your syntax would confuse go programmers
<Tetralux>
So - there's several things here.
<Tetralux>
First - "doesn't work with patterns" - elobration required.
<Tetralux>
Second - "parsing much harder" - citation needed.
<companion_cube>
well, you have to parse a whole pattern before seeing the `:=`
<Tetralux>
Third - "which one is which" - I'm not sure I understand.
<companion_cube>
(which indicates that it's actually a pattern that should be parsed)
<andrewrk>
var/const you know it's a var decl with 1 token
<andrewrk>
whereas expressions can be arbitrarily long. this is the worst case of parsing ambiguity
<_Vi>
Submitted proposal issue about --sloppy mode: #3320.
<andrewrk>
thanks _Vi
<companion_cube>
(in rust: `let <pattern> = …`, doesn't get simpler)
<_Vi>
That `@todo` is a good candidate for being a sloppy-only function.
<companion_cube>
`let (mut x, y) = (1,2);`
<Tetralux>
andrewrk: Surely you'd just iteratively parse the expression?
<Tetralux>
I don't completely understand the advantage of being able to know that it's a decl in just one token.
<Tetralux>
Also, it's just names or _ on the LHS.
<companion_cube>
because what's on the left of `=` in a decl, isn't an expression
<Tetralux>
It's not like it's a fancy expression.
<fengb>
Expressions can be almost anything during parsing
<companion_cube>
how do you even differentiate from assignment?
<fengb>
Unless it’s defined to not be an expression but something specific
<companion_cube>
x.* = 42;
<Tetralux>
These arguments are not making sense to me.
<Tetralux>
Obviously the LHS is just an ident.
<Tetralux>
You can tell between an assignment or a decl because an assignment omits the type and is just "=" rather than ":" _and_ "=".
<Tetralux>
x := 42; x = 42;
<Tetralux>
x: i32 = 42; x = 42;
<fengb>
Expression by definition is arbitrary and recursive. You’re asking for something that’s not a general expression but rather a defined LHS
<companion_cube>
I find that quite confusing to read, tbh
<companion_cube>
better to be explicit about scoping
<Tetralux>
fengb: You cannot have a general expression as the var name as it is.
<Tetralux>
`var f(x) = 32;` does not compile in any circumstance.
<companion_cube>
what happens with multiple return values, or destructuring, or… ?
<Tetralux>
companion_cube: What happens?
<fengb>
But that doesn’t happen at parse time
<companion_cube>
well your idea breaks :D
<Tetralux>
x, y, z, _ := f();
<fengb>
Unless you bloat the parser
<companion_cube>
you need arbitrary lookahead to find the `:=`
<Tetralux>
companion_cube: I don't really get why that's so bad - you have a stateful parser already.
<Tetralux>
You have all the tokens in memory anyway.
<Tetralux>
You're just iterating over them.
<companion_cube>
good grammars should have 1-token lookahead, thank you very much :p
<Tetralux>
Citation needed )
<Tetralux>
:) *
<companion_cube>
"should" is an expression of taste
* Tetralux
grins
<companion_cube>
but it makes such grammars easy to parse with a variety of techniques
<companion_cube>
hand written, parser generators, parser combinators, etc.
<Tetralux>
I'm not hearing an advantage xD
<Tetralux>
You can already parse extremely quickly.
<companion_cube>
because we're not agreeing on any of the basic axioms :D
<Tetralux>
Even with a basic recursive descent.
<companion_cube>
for me, `let/var/…` is: more explicit, more readable, easier/faster to parse, more general (you can have patterns, not just single variables)
<mikdusan>
if a `:` or a `:=` token follows an identifier, it's an initialization at stmt level, or a arg-spec for fn
<companion_cube>
mikdusan: still more complicated with multiple return values
wootehfoot has joined #zig
<companion_cube>
(I guess you can see the `,` already, but ugh)
<Tetralux>
It's the same complexity.
<Tetralux>
They're not different.
<dimenus>
what about let instead of const for decls?
<dimenus>
:D
<Tetralux>
x, y, z = f(); var x, y, z = f();
<companion_cube>
\o/
<Tetralux>
x, y, z := f(); *
<companion_cube>
Tetralux: you need to find the := first before knowing x,y,z are varaibles to bind
<companion_cube>
(rather than assign)
<companion_cube>
assignment could also stuff like `x[0] = …`
<companion_cube>
which binding doesn't allow
<companion_cube>
(something rvalues something, forgot the C++ terminology)
<companion_cube>
`x.foo = …` is allowed; `x.foo := …` doesn't make sense. So, lookahead needed.
<Tetralux>
companion_cube: The only situation in which `x,` is valid is in a var decl...
<mikdusan>
what?
<companion_cube>
Tetralux: that's kind of ad-hoc though. but if you like it…
<Tetralux>
Is it?
<companion_cube>
(I'll take my `let`-binding, thank you)
<Tetralux>
Name any other reasonable example of it?
<Tetralux>
It's the same as saying that "var x` is only valid in a var decl.
<dimenus>
Tetralux, we really need GB in here :P
<companion_cube>
`var <any pattern>`, rather
* Tetralux
grins.
<companion_cube>
because when you see `var`, you know what to parse next
<Tetralux>
where <any pattern> =
<Tetralux>
x, y, z =
<Tetralux>
x =
<dimenus>
andrewwrk: I thought I saw you once recommend replacing const with 'let' for decls, do you have any recent comments on that?
<companion_cube>
{.x, .y} =
<companion_cube>
(x,y) =
<companion_cube>
etc.
<dimenus>
i think the big difference here is that zig has a lot more expressions than Odin does
<Tetralux>
As I said -- x, y, z :D
<dimenus>
most things are a statement in Odin
<mikdusan>
fundametally you guys are arguing prefix (rpn) vs infix :)
<companion_cube>
(I know, if you imitate Go you can deal with it because its expression language is so poor)
* Tetralux
scratches head
<companion_cube>
dimenus: guess that's why I'm on #zig? 🤔
<dimenus>
also, zig doesn't have separate return values
<dimenus>
or rather multiple return values
<Tetralux>
I think that's a missed opportunity, personally.
<dimenus>
eh, don't really need it
<dimenus>
i was annoyed by Zig's style of error handling back in 2017 when I first tried it
<companion_cube>
I'd rather have tuples, woo
<dimenus>
i've completely come around now
<Tetralux>
If you like writing structs all the time, or write code exactly once, then sure.
<Tetralux>
I do not.
<_Vi>
`let`/`let mut` may be nicer match for Zig than `const` / `var`.
<Tetralux>
I like simplicitly.
<Tetralux>
simplicity(
<companion_cube>
we all like simplicity
<Tetralux>
*
<companion_cube>
we just have different notions of simplicity
<Tetralux>
Multi-return is strictly simpler - you don't have to leave the definition of the thing you're working on.
<dimenus>
i think var is fine, why would we need two keywords for a mutable binding?
<Tetralux>
You don't bounce around your code as much.
<fengb>
More complex implementation
<Tetralux>
And don't have multiple things you must read before reading the fn sig.
<fengb>
So not strictly simpler
<Tetralux>
fengb: Identically complex, in the way you mean, actually.
<companion_cube>
Tetralux: tuples is strictly as simple
<Tetralux>
.. which is how you'd implement multi-return.
<companion_cube>
tuples are values, so it's even simpler
<Tetralux>
Are we agreeing? xD
<companion_cube>
not totally
<companion_cube>
I'm arguing for tuples, you for multiple-return values
<Tetralux>
I would only have tuples as the implemention for multi-return.
<Tetralux>
I wouldn't have them in the language.
<companion_cube>
exactly why we're not agreeing :p
<Tetralux>
I'm not sure why you'd want them though xD
<Tetralux>
My experience with Julia only seems to introduce complexity by having them.
<Tetralux>
And Python, for that matter.
<companion_cube>
you've never had tuples in a typed language, then? :/
<companion_cube>
in OCaml and rust they're absolutely great
<companion_cube>
it's simple a nameless struct with ordered fields, there's 0 complexity
<Tetralux>
In what other situation would you use them for that an array or struct would not suffice?
<Tetralux>
Or well - "suffice" - not the right word.
<companion_cube>
it's totally different from an array; as for a struct, well, sometimes you don't want to name super simple things
<companion_cube>
(eg returning stuff)
<fengb>
Arrays are homogeneous collections
<Tetralux>
Yeah - but in what situation would you use them for?
<Tetralux>
Because I think you'd only really want them for named/non-named return values.
<Tetralux>
In which case, you don't need them in the language.
lukeholder has joined #zig
<Tetralux>
You just need multi-return values that can be named.
<fengb>
Tuples? Where position makes more sense than naming
<Sahnvour>
andrewrk: interesting. hopefully I was able to do my debugging in zig0 lately, but will give it a try
<Tetralux>
Sounds like return values to me :)
<fengb>
But it can also be passed around without unwrapping
<Tetralux>
fengb: g(f()); return f()
<Tetralux>
.. where f has multi-returns.
st4ll1 has joined #zig
<dimenus>
how much swap do you guys use when you build llvm?
<dimenus>
i keep getting owned by the oom killer
<andrewrk>
dimenus, -DCMAKE_BUILD_TYPE=Release makes it use much less
<dimenus>
oh wow, can't believe i skipped that
<dimenus>
i've built LLVM plenty of times on windows and always included that
<andrewrk>
I always do that for clang. When I do a debug build of LLVM, I don't do any build parallelization
<dimenus>
andrewrk: do you build all targets?
<Sahnvour>
8GB RAM is enough on my windows but I guess it swaps from time to time
<dimenus>
windows behaves far better under memory pressure in my experience
<dimenus>
yeah this is far better. cpu's basically pegged at 100% but i'm not experiencing memory/swap pressure at all
<TheLemonMan>
the linking phase takes an awful lot of memory, I've tried to tame it by setting LLVM_PARALLEL_LINK_JOBS and using gold as linker instead of ld
<TheLemonMan>
yay, the mips PR is green!
<TheLemonMan>
and it even builds just fine with musl (with a small patch that I should upstream sooner or later)
<andrewrk>
nice!
<andrewrk>
sorry bout the mv std/ lib/ thing
<andrewrk>
there was never going to be a good time to do it
<Sahnvour>
TheLemonMan: did you try lld ?
<TheLemonMan>
no problem, git rebase figured everything by itself
<andrewrk>
oh, brilliant
<TheLemonMan>
Sahnvour, yep, but I'm partial to the GNU toolchain :P
<andrewrk>
std lib mips support is pretty bad ass
<andrewrk>
TheLemonMan, ready for merge?
<_Vi>
How do I zero-initialize static array without specifying its length again?
<TheLemonMan>
andrewrk, sure thing, just in time for 0.5.0
<andrewrk>
done
<TheLemonMan>
I wonder what's next? PPC64? i386? :)
<andrewrk>
my personal preference: -march=native for windows
<andrewrk>
that looks like it will not be fun to debug though. I've taken a few stabs at it
<TheLemonMan>
it's not fun because it's windows
<dimenus>
scientes: how's the SIMD patch looking recently?
<scientes>
It got rebased, but I am not sure if Andrew will look at it again before releasing
<scientes>
yeah the tests passed (which includes arm and arm64!)
<dimenus>
my app still segfaults
<dimenus>
i'll test again once LLVM finishes building
<scientes>
dimenus, that is not a segfault, it is a failure to build, right. The one about sizing unions
<dimenus>
nah, it actually segfaults on assignment
<dimenus>
more recently
<dimenus>
again, i'll verify in the next 30 mins
<TheLemonMan>
soo, mips is promoted to tier 2?
<scientes>
there are like 6 mips ABIS so you should be specific
<Tetralux>
What is MIPS used for?
<Tetralux>
Embedded?
<TheLemonMan>
o32 of course
<scientes>
cheap routers
<scientes>
TheLemonMan, big or little
<Tetralux>
I've never come across any use of it. :)
<TheLemonMan>
scientes, mipsel, BE support in the compiler is flaky
<scientes>
Tetralux, 99% change your router uses MIPS
<scientes>
only the expensive ones use arm or x86
<Tetralux>
What's the hallmark of MIPS? - Like, what's the usecase?
<TheLemonMan>
PS2 and PSP too
<TheLemonMan>
and PS1 of course, let's not forget about it... and N64 too!
<scientes>
oh yeah, MIPS was hot shit on the N64!
<TheLemonMan>
it's a pretty nice ISA
<TheLemonMan>
from the ABI point of view is a clusterfuck tho
<Tetralux>
They open sourced it recently. Huh.
<andrewrk>
scientes, I'm not planning to merge any more for 0.5.0 but will give it priority in the next cycle
<andrewrk>
TheLemonMan, ah yes, good call. I'll update that now
<companion_cube>
Tetralux: g(f(x).1)
<companion_cube>
if it's the second return value of `f` you want to give `g` ;)
<andrewrk>
TheLemonMan, the update will get pushed monday; I have other misc. updates for the home page to launch as well with the release
<Tetralux>
companion_cube: g(f()) would pass all the return values in order to g. :)
<companion_cube>
assuming you have the exact same signature, how often does thatwork?
<Tetralux>
That I do not know.
_Vi has quit [Ping timeout: 246 seconds]
<Tetralux>
fengb was talking about how tuple can be passed around without unwrapping them - that example, along with being able to directly return all the return values with `return f()` where f has multi-return is an example of that working without tuples.
<Tetralux>
You probably would not do that though.
<Tetralux>
Because you'd probably want to check one of them for an error or something before knowing that you'd need to return anyway.
<companion_cube>
`return f().1;`
<companion_cube>
`return (try f()).1;` ;)
<Tetralux>
I'd do `x, _ := f(); return x;`
<companion_cube>
this isn't go, Zig has proper error handling
<Tetralux>
(Because I'd probably want to check one of the other values anyway.
<Tetralux>
So really
<Tetralux>
x, y, _ := f(); if y {}; return x
<Tetralux>
Something like that
<companion_cube>
so you think
<Tetralux>
I mean, most of my Odin code is of that form.
<companion_cube>
tuples are also useful in things lie iterators
<Tetralux>
At least that that used multi-returns.
<Tetralux>
In what way?
<companion_cube>
well you can have an iterator of tuples
<companion_cube>
like, if you iterate over the key/value pairs of a hashmap
<Tetralux>
I'd rather something like 1)
<Tetralux>
for x, y in map {}
<Tetralux>
Or 2)
<Tetralux>
for entry in map { /* use entry.key , entry.value */ }
<companion_cube>
so, no first class iterators? :p
<companion_cube>
now you want to name everything?
<Tetralux>
I did not say "no first class iterators".
<Tetralux>
Quite the reverse, in fact.
<companion_cube>
`tbl.iter().map(|(x,y)| (y,x))`
<Tetralux>
That looks awful.
<companion_cube>
what's the type of the iterator then? :p
<companion_cube>
that's very simple, please
* Tetralux
grins
<companion_cube>
`tbl.iter().map(|e| {.key: e.value, .value: e.key})` is quite the mouthful
<fengb>
Tetralux: you're making adhoc tuples everywhere while trying to avoid tuples
<companion_cube>
^
<Tetralux>
fengb: I mean - not ad-hoc.
<companion_cube>
totally ad hoc
<Tetralux>
Tuples only complicate simple things so far as I can tell.
<companion_cube>
I actually know no language I'd call clean that has multi-return functions :s
<companion_cube>
only untyped languages and weird stuff like Go
<fengb>
Those are literally tuples you're using. You just didn't give them a real syntax
<Tetralux>
Multi-returns make sense that a tuple-like thing is used for them - but you don't actually use them in that.
<Tetralux>
The language does, as it were.
<Tetralux>
fengb: That's the point.
<Tetralux>
I would not give them a syntax.
<Tetralux>
Or at least
<Tetralux>
I'm not inclined to.
<companion_cube>
except for all the constructs where you do
<fengb>
A tuple is just a data structure where position matters. for x, y in blah implies x=[0], y=[1]
<companion_cube>
so instead of 1 notion of tuples, you have multi bindings in varaibles, `for`, etc.
<fengb>
So that's a tuple. And Zig basically demands a syntax for a concept that exists
<andrewrk>
I'll publish a draft of 0.5.0 release notes on saturday evening, and anyone will be welcome to suggest improvements in the form of pull requests
<Tetralux>
Referring to the elements of a tuple with x[0], x[1] etc tells me nothing about what they mean.
<companion_cube>
(I know no one cares about academia here, but I've never seen anyone talk about multi-return, it's always done with tuples because it's infinitely simpler)
<Tetralux>
They make some sense to use as the mechanism for how multi-returns work, however.
<fengb>
All pretending to use what will be tuples underneath the covers... but not tuples?
<companion_cube>
fengb: 💯
* Tetralux
sighs.
<Tetralux>
I wish people would see what it is I'm saying and not cling to an idea sometimes :)
<companion_cube>
we could say the same of you :p
<Tetralux>
All it is, is that you have multiple returns.
<companion_cube>
and multi iterators
<Tetralux>
They way you do that is the same data layout as what you might call a tuple.
<companion_cube>
and multi assignment
<Tetralux>
But you don't provide a way for a programmer to make or otherwise use a tuple.
<companion_cube>
(and multi for)
<Tetralux>
Beyond multi-assignment and multi-declaration.
<companion_cube>
and multi for and multi iterator
<companion_cube>
it's really a mess :D
<Tetralux>
Multi-for?
<companion_cube>
for i, x in …
<Tetralux>
That's only a tuple in appearance xD
<companion_cube>
or is it `x, i`?
<Tetralux>
And even then - that's a little tenuos.
<Tetralux>
tenuous*
<Tetralux>
I wouldn't consider that a tuple.
<Tetralux>
I'd consider that part of the syntax for the 'for' construct.
<Sahnvour>
companion_cube: I hope you're wrong that no one cares about academia :)
<companion_cube>
Tetralux: the point is, with tuples, you don't need any of this special stuff. You just have expressions
<companion_cube>
Sahnvour: well, no one wants to hear about dependent types :p
<companion_cube>
and andrewrk doesn't like `noreturn` as a type :(
<companion_cube>
(forgot who was arguing about it, but it made a lot of sense to me)
<fengb>
I don't care about academia :P
<companion_cube>
Tetralux: for me, "simple" means predictable and uniform (principle of least surprise). Tuples, being normal values, fit this requirement
<andrewrk>
companion_cube, it made sense to me too, I think I was a bit more argumentative than I actually felt about it
<companion_cube>
there's no need to think about the meaning of functions returning several values or stuff like that; functions always return one value
<companion_cube>
:D no worries
<companion_cube>
it's a bit weird, but `noreturn` fits well into the algebra of types, as a zero
<fengb>
Except when it returns no value though :P
<companion_cube>
fengb: it does, it returns void
<Tetralux>
I don't really understand the need to simplify the idea of "a function can return multiple values as a blob" - I don't see the need to simplify that.
<companion_cube>
I mean, it's simpler to have `unit` for that, but anyway
<Tetralux>
Indeed, it's not "one value" - it consists of multiple values.
<andrewrk>
if doing the official "zero" type theory thing results in simplifications of semantics or the way to think about how the type system works, I'm all in. If it creates more edge cases, then I'm against it
<Tetralux>
You're hiding complexity.
<companion_cube>
Tetralux: functions returning one value have been around for a lot longer
<companion_cube>
and are simpler to reason about
<companion_cube>
andrewrk: it simplifies a lot of things, like computing the size of a type
<andrewrk>
as an example, using the zero type to "cancel" a union field, while I understand why the type theory would say to do that, it also seems pretty confusing and unnecessary if you're reading code
<companion_cube>
it's useful when you instantiate templates, of course you don't write `noreturn` in an union directly
<companion_cube>
(that'd be weird indeed)
<andrewrk>
companion_cube, how does it simplify computing the size of a type?
<Tetralux>
companion_cube: I don't really understand what functions always having returned one value being the case for a long time has anything to do with it xD
<companion_cube>
andrewrk: I mean, more for canonizing a type
<companion_cube>
a struct with noreturn in it, becomes noreturn (like multiplication with zero)
<Tetralux>
Returning one value is limiting - "Simple! You can return an arbitrary number of values now."
<companion_cube>
a struct with `void` in it can remove the `void` (like one in multiplication)
<andrewrk>
companion_cube, ah, yeah, that is actually a pretty compelling argument. it's a lot like using void as the HashMap value type
<companion_cube>
Tetralux: how do you compose functions?
<companion_cube>
andrewrk: yes exactly
<Tetralux>
The logic seems fairly easy to extend to that, in my mind.
<Tetralux>
How do you compose?
<Tetralux>
Be more specific.
<companion_cube>
if you have `Result<T,E>` as in rust (or something like that), using `E=noreturn` in contexts without errors makes it 0-cost
<companion_cube>
Tetralux: function composition?
<Tetralux>
Give me an example of what you mean that you don't understand how it would work.
<andrewrk>
companion_cube, yes, this reasoning is affecting my stance on the topic
<companion_cube>
andrewrk: 🎉
<companion_cube>
it's also like: `e1; e2` where `e1: noreturn` simplifies to `e1;` as e2 is dead code
<companion_cube>
and for tagged enums (ahem, sum types :-°), the size is (sizeof(tag) + max(sizeof(each struct))`
<companion_cube>
if there's only one struct, the tag is trivially `void` (no information stored in it) so you can simplify it to the only struct remaining
<companion_cube>
Tetralux: more like, I'm used to lambda calculus as a basis, in which functions actually take and return one argument ;)
<companion_cube>
I imagine you can do something similar with multi-return, it's just weird
<Tetralux>
Oh yeah - that's your problem right there xD
<Tetralux>
Computers are not mathematics xD
<Tetralux>
They are structured.
<companion_cube>
mathematics not being structured, that's a new one :D
<Tetralux>
Functions with single-returns is status-quo.
<Tetralux>
But there's not actually any good reason for it.
<andrewrk>
dimenus, neat- experimenting with using @Vector to back linear algebra
<Tetralux>
companion_cube: Also P.S: I did not say that xD
<companion_cube>
you implied it, is all
<Tetralux>
I said that computers are not math-first systems.
<Tetralux>
They are structure-first.
<Tetralux>
Like - you have fixed-size ints, as a trivial example.
<Tetralux>
You have structs.
<Tetralux>
Math is not integral to this.
<companion_cube>
sorry to break it to you, but type theory has dealt with that for a long time :D
<Tetralux>
Sorry to break it to you, but type theory does little to help you understand how to make a machine do its' job in a fast reliable way that actually gets work done. xD
<Tetralux>
It's a whole field of stuff that you do not need to do programming.
<Tetralux>
And having be the reason that multi-returns make no sense, is a good example of why XD
<andrewrk>
dimenus, I look forward to someone doing a perf comparison of doing that vs backing it with arrays
<companion_cube>
no the disguised integer
Hirezias has joined #zig
<Tetralux>
struct { tag: int, value: *void }
<Tetralux>
Seems like a structure to me.
<Tetralux>
:)
<companion_cube>
-_-
<Tetralux>
Like - don't get me wrong - I would not be at all surprised if someone was able to come up with these ideas or whatever - based entirely from maths.
<Tetralux>
But that's not how I'd arrive at it.
<companion_cube>
as they did :D
<companion_cube>
no, but you can learn from other people, too
<Tetralux>
Occamm's Razor.
<companion_cube>
there's a middle ground between pure academia, and pure hacking
<Tetralux>
It's literally just a simple way to represent multiple values.
<fengb>
C++? 🙃
<Tetralux>
This is a very simple construct.
<companion_cube>
fengb: :D
<dimenus>
andrewrk: i can't completely take credit, it's based on directxmath & glm
<companion_cube>
Tetralux: sum types are also a simple way of representing multiple values
<companion_cube>
while also offering a case distinction
<Tetralux>
You could represent them in such a way, sure.
qazo has quit [Read error: Connection reset by peer]
<Tetralux>
But I don't really know why you would, really.
<Tetralux>
You have all the info that a sum type would provide you already.
<Tetralux>
What would that bring to the table?
<Tetralux>
Generics? That infect all your types? xD
<companion_cube>
better safety
<companion_cube>
well, you do know that Zig has generics? 🤔
<Tetralux>
Sum types give better safety than multiple-returns/
<Tetralux>
?
<companion_cube>
well, `Ok<T> | Error<E>` is cleaner than `(T,E)` + checking if the error is nil first, yes
<Tetralux>
Also Zig generics are thankfully not yet at a 'Peekable<Rewindable<Iterable<byte>>>' yet. :)
<Tetralux>
I think that depends on a few things.
<andrewrk>
dimenus, scientes has a difficult task with the SIMD patchset. I've been slowly cherry-picking commits from it to upstream, and he's had to keep it based on upstream for a long time
<Tetralux>
Namely how generics are implemented and how they are used.
<Tetralux>
And whether that's ergonomic.
<Tetralux>
But the latter is closer to the machine.
<companion_cube>
here I'm just talking about sum types, really, not generics
<companion_cube>
(or tagged unions, ofc)
<dimenus>
andrewrk: yeah, i know it's a large task. I'm only bringing it up because he said his patchset was passing tests (and mergable)
LargeEpsilon has quit [Ping timeout: 240 seconds]
qazo has joined #zig
porky11 has joined #zig
_Vi has joined #zig
qazo has quit [Read error: No route to host]
johnLate_ is now known as johnLate
<mikdusan>
this macos ci. like a _rock_ /s
<andrewrk>
I'll be sad if the 0.5.0 commit fails CI
<companion_cube>
damn, azure CI looks so much nicer than GCB
Ichorio has joined #zig
chigau has joined #zig
SimonN has quit [Remote host closed the connection]
chigau has quit [Remote host closed the connection]