<betawaffle>
idk, maybe i'm wrong an they are both a bit unpleasant, but Zig has more safety options
<betawaffle>
take this go: uint64(uint32(int32(x)))
<betawaffle>
that's how you 1. sign extend x to 32 bits, 2. zero extend that to 64 bits
<betawaffle>
but you have to really understand the semantics of those cast
<betawaffle>
with zig, it's more obvious what someone's doing
<fengb>
Isn't that the same as `@as(u64, @as(u32, @as(i32, x)))`?
<fengb>
Or does `uint32(int32)` actually translate to `@bitCast(u32, i32)`
<betawaffle>
yeah, but what if x is bigger than an int32? in zig that would compile-error
<fengb>
Oh, does Go just give up?
<betawaffle>
yeah, it's a bit cast
<fengb>
Damn... okay I think Zig wins here :P
<betawaffle>
casting between signed/unsigned of the same type is a bit cast
<betawaffle>
casting to a bigger size will sign or zero extend, depending on the type
<betawaffle>
and casting down...
<betawaffle>
is just truncation
<betawaffle>
though i can't remember about signed truncation
* betawaffle
looks at the go spec
<fengb>
Hmm... is Zig an exception when it comes to explicitly splitting up those casts?
<fengb>
(How does Rust do it)
<betawaffle>
rust is completely explicit about all of that, i think
metaleap has joined #zig
<fengb>
`Casting from a larger integer to a smaller integer (e.g. u32 -> u8) will truncate`
<fengb>
Rust's `as` keyword semantics are just as overloaded :(
<betawaffle>
hmm, the go spec doesn't even have the word "cast" in it
<fengb>
Maybe this is an advantage towards not having a keyword, since it's ambiguous what should be done
<betawaffle>
ah, they call it conversions
<fengb>
Of course they do ;)
<betawaffle>
"Conversions between numeric types"
<betawaffle>
1. "When converting between integer types, if the value is a signed integer, it is sign extended to implicit infinite precision; otherwise it is zero extended. It is then truncated to fit in the result type's size."
<fengb>
"The transmute function is very simple, but very scary. It tells Rust to treat a value of one type as though it were another type. It does this regardless of the typechecking system, and completely trusts you."
<fengb>
Sometimes I wish Rust would respect me :(. Bitcasting is a pretty common low level concept
<betawaffle>
that's the same as zig's @bitCast
<fengb>
Yeah but it's very! scary!
<betawaffle>
right, because in rust representations can be undefined
* mq32
takes his f32, casts it to u32, applies some magic 0x5f3759df to it and converts it back
<betawaffle>
i'm such a huge fan of zig's arbitrary integer sizes
<fengb>
LLVM is capped at 128 though :(
<betawaffle>
what does zig do with larger ones?
<BaroqueLarouche>
mq32: isn't that the Quake3 Inverse SqRoot constant ?
<fengb>
betawaffle: right now it crashes with a compiler error
<fengb>
Not very graceful
<betawaffle>
well, i tend not to need things larger than 128, but stuff like u29, u7, etc are really useful
<fengb>
It's considered a bug so it'll be fixed soon™
<mq32>
BaroqueLarouche, indeed it is
<fengb>
Ah yeah, I just had to use a bunch of i7s because it was per spec
<betawaffle>
right, weirdly sized signed integers are a *huge pain* in other languages
<fengb>
I'm really unhappy to use the bits of f64 :(
<fengb>
But hey it works
<metaleap>
fengb: "LLVM is capped at 128 though" --- llvm langref: "The integer type is a very simple type that simply specifies an arbitrary bit width for the integer type desired. Any bit width from 1 bit to 223-1 (about 8 million) can be specified."
<metaleap>
which one is it =)
<betawaffle>
one thing that's still sort of annoying in zig is i'd like to be able to shift a an integer's bits between sizes too, like a special right and left shift that shifts bits but also shrinks/grows the size
<betawaffle>
(but obviously it'd need to be a different operator
<mq32>
betawaffle: why should it be another operator?
<fengb>
betawaffle: sounds like a candidate for std.math function
<mq32>
i think it's quite reasonable that a shift-left of 3 bit will increase the type size by 3
<betawaffle>
mq32: because how'd you do regular shifting?
<mq32>
if you want to discard the bits, use @truncate
<mq32>
that will make your intent much clearer
<betawaffle>
ah, interesting. well the other problem is that the shift may not be comptime-known, right?
<fengb>
That doesn't make sense at the language level. Builtins should map to assembly
<betawaffle>
(only comptime bound)
<fengb>
(Or some notion of an existing assembly instruction)
<mq32>
betawaffle, you may not use any type for shifting that would shift more than te number of bits
<mq32>
so (a<<b) will require b to be u3 when a is u8
<betawaffle>
right, but what i'm saying is your shift could be a runtime-known *value* which is comptime-known to still be valid
<betawaffle>
and you wouldn't know what type comes out the other side?
<mq32>
the maximum possible type
<betawaffle>
or would it always be the largest size possible, ohhh
<betawaffle>
right ok
<betawaffle>
that could definitely work
<betawaffle>
i'd like to see that implemented
<grayhatter>
is zig trying to abstract away some of the semantics of how the hardware actually does it's work?
<fengb>
add a std.math function
<fengb>
Shouldn't be too hard
<fengb>
grayhatter: not really. We try to be more explicit about things though
<fengb>
If it's ambiguous across machines, the language tends to be conservative and crash on undefined behaviors, and we have ways to force one strategy
<betawaffle>
do we already have std.math functions for bit-range extraction?
<grayhatter>
I'm thinking that if << will alter the type of the result, that's abstracting away the physical types the cpu will use
<betawaffle>
grayhatter: it's be like sign/zero-extending first, then shifting
<grayhatter>
s/cpu/arch
<fengb>
grayhatter: I agree it doesn't make sense. That's why I'm advocating against hijacking the operator. We do that sort of thing in stdlib though
<grayhatter>
I understand that, but in C, if you bitshift past your size, it doesn't grow the size for you, it'll just truncate
<betawaffle>
right, but zig never lets you do that anyway
<fengb>
That's well defined in Zig to be illegal. The type system won't let you do that
<betawaffle>
(without a separate operator)
<grayhatter>
I agree that something like that should be explict, over implicit. But I don't think I'd want my language to change the size of memory block I'm using
<fengb>
+1
<fengb>
I've been doing this and getting realignment is painful: `stack: []align(4) u8`
<fengb>
Should I switch to u32 even though the bookkeeping is slightly less intuitive?
<fengb>
(It feels weird to stick arbitrary data into []u32)
<grayhatter>
I'm also of the opinion that stdmath should be allowed to change memory size for things it owns. numpy is an example of getting it right. They allow you to controll the memory, but if you choose not it, they'll do it for you (and correctly)
<grayhatter>
well, perhaps math, not stdmath... but I'm only half paying attention to zigs libs
<fengb>
`sw_vers -productVersion` reports the macos version
<fengb>
Not sure which one should be used >_>
<andrewrk>
ok yes it's the darwin version. I think we want to use the macos version though. anyone know how to do `sw_vers -productVersion` programatically? e.g. what is sw_vers doing
<andrewrk>
supposedly this is open source but apple does not make things easy to find
<andrewrk>
woo, in the os-version-range branch, zig correctly detects the native C ABI as "musl" on alpine linux
<BaroqueLarouche>
nice!
SyrupThinker is now known as syrupthinker
<andrewrk>
I'm rather pleased with how that works
<mikdusan>
andrewrk: `uname -r` has little to do with `sw_vers`. `uname -r` iirc is the kernel version. so think of it as linux returning "5.4.15" . then apple versions their brand macOS and it is reported via `sw_vers`, or the expensive `system_profiler`
<mikdusan>
apple's `10.15.3 (Catalina)` would be analogous to ubuntu 19.04
<andrewrk>
that makes sense. but I think that zig's os version range should be macos versions not darwin versions. whereas on linux I think it makes sense to be linux kernel versions, not distro versions
<andrewrk>
having looked at the implementation of sw_vers, I think native macos version detection will attempt to execute sw_vers rather than requiring to link against CoreFoundation :-/
_Vi has quit [Ping timeout: 248 seconds]
<andrewrk>
that can potentially be solved later, but that's a whole new set of problems to tackle
<mikdusan>
the cheapest way would be to read /System/Library/CoreServices/SystemVersion.plist or somesuch and fallback to sw_vers
<mikdusan>
yup optimize later
syrupthinker has quit [Quit: ZNC 1.7.5 - https://znc.in]
<andrewrk>
oh, there's an xml file with the answer right there?
<mikdusan>
plist is xml'ish. but yeah
<andrewrk>
damn we don't have an xml tokenizer yet. that's all that is needed here
<andrewrk>
hmm I think this might be a nice set of contributor friendly issues
<andrewrk>
I think people would enjoy doing native OS version detection
<BaroqueLarouche>
or doing a XML library
<andrewrk>
yes, just a tokenizer
<andrewrk>
you can get really far and avoid a lot of issues by only tokenizing xml
<metaleap>
and in fact, for 80% of "mere lookup needs", 1 or 3 careful stringIndexOfs will get you the answer if its known to occur 0x or 1x in the file =)
<metaleap>
(not pretty, but neither is 3rd parties sticking to xml)
<Cadey>
andrewrk: does Zig support the x32 ABI on Linux?
<Cadey>
or in general
<Cadey>
that uses 32 bit function pointers
<andrewrk>
yes, have a look at `zig targets | jq .abi`
<Cadey>
:+1:
<mikdusan>
there is also a decent curation of darwin -> macOS history:
<metaleap>
why does this dude bother with windows anyway, is he a game dev? it's quite irrelevant for "infrastructure software" (as he calls it) in 2020
<metaleap>
dimenus: not fields only decls AFAIK
<TheLemonMan>
dimenus, no fields, only declarations
<mq32>
metaleap: i don't think so. windows is still really widespread in infrastructure ;)
<mq32>
maybe not in "network" or "it" infrastructure
<mq32>
how many hospitals run desktop linux to manage their stuff?
<BaroqueLarouche>
Windows is still ~90% in the market share
<TheLemonMan>
BaroqueLarouche, yo, how's the zig-on-gba project going?
<BaroqueLarouche>
TheLemonMan: Took a bit on a break to focus on zigimg, last time I was working on required lib stuff to make objaffine demo. Like adding Fixed Point math and sin/cos table
<BaroqueLarouche>
I should push this branch public, will do that either tonight or tomorrow
<BaroqueLarouche>
on zigimg, I did a huge refactoring to have a proper generic Image class that can read different image format and adding PCX support by adapting mq32's code https://github.com/mlarouche/zigimg/tree/AddPCXSupport
wootehfoot has joined #zig
jessermeyer has joined #zig
<jessermeyer>
Does cImport() internally leverage translate-c?
<TheLemonMan>
yes
<jessermeyer>
Thanks.
<jessermeyer>
I apologize for asking this again. I've forgotten. Does translate-c parse the c code as is, or does it let clang pre-process the source file first?
<jessermeyer>
(so it sees both macros + macro expansions)
<BaroqueLarouche>
jessermeyer: How do you call COM api in your code, like D3D RenderTargetView and such? Just curious how you did on your side
<TheLemonMan>
the latter, the C code as-is is pretty much useless
<jessermeyer>
I call the v-table macros directly.
<jessermeyer>
When using COM
<jessermeyer>
But today I've been exploring Vulkan instead of DX12 since the COM is driving me nuts.
<jessermeyer>
I was having enough problems getting the v-tables populated correctly originally that I never explored being clever about it.
<jessermeyer>
So most of my COM calls are quite direct.
dimenus has quit [Remote host closed the connection]
<metaleap>
lsp slow-mo-progress update: took a break from ast-traversals for a nicely working little build-on-save with live diagnostics-sync: https://i.imgur.com/uHejIE9.png
<metaleap>
now with fmt-on-save and build-on-save and symbols-listing i got a decent productivity base to tackle the actual meaty needs. jump-to-def / peek-definition really has to happen next & soon. dammit
<jessermeyer>
nice!
<metaleap>
best part is the as-you-type parse-error wigglies. to not annoy, they're marked as infos (blue) instead of "danger"-red
<andrewrk>
metaleap, are you doing anything with the semantic analysis dump?
<betawaffle>
i'm debating whether to just ignore the fact that in NBT, bytes are supposed to be "signed"
<betawaffle>
it's seems super meaningless to specify signed-ness as part of the encoding
<metaleap>
mq32: i'll move things to a single repo for ease of pulling/updating but for now its spread across 4 libs in 4 separate repos and the @import()-paths assume that those exist side-by-side each other
<betawaffle>
and the way go does slices and signedness is just awful
<mq32>
metaleap: what about submodules?
<metaleap>
mq32: yeah the single-repo would actually be mirroring these 4 as git submodules, when i get to that (when i have sth real to offer not just the early gimmicks)
<metaleap>
andrewrk: not yet, it's planned for after once I got as far on ast alone (and perhaps some of the more trivial expr-eval opportunities) as it'll take me.
<metaleap>
i also assume --- could I be wrong? --- that the semantic-analysis-dumps will be based on the compilers lazy eval, hiding things that the sources themselves reveal and the LSP UX also should
frett27 has joined #zig
<andrewrk>
that's correct
<mq32>
andrewrk: how much work would it be to implement an AST dump of the parser output?
<metaleap>
so i'll get the ground truths straight from sources as far as that approach can go, before deferring for extra intel goodies to ad-hoc json dumps (seem to land ~3MB depending how much of std is in there) --- right now i can load ASTs for ~400 source files into RAM in 3-4 seconds startup time, then only very rarely on-edit refresh one or the other in a tiny handful of millis. and thats only debug-build. too delicious to not exploit to the max, first
<andrewrk>
mq32, why would you need that? use std.zig.parse
<andrewrk>
metaleap, you should be able to implement jump-to-definition without semantic analysis. but it will take detours through any aliases (e.g. pub const foo = bar; )
<andrewrk>
true jump-to-definition will require semantic analysis, and the answer could be different depending on build mode or other build-time options
<metaleap>
andrewrk yeah i'm gonna have to impl *some* amount of the more trivial evals
<andrewrk>
const MyType = if (isPrime(x)) Foo else Bar;
<metaleap>
ie i certainly want to be able to resolve @import("my"++"file.zig")
<mq32>
andrewrk: i want to test out how good a pure text-based docgen would be
<mq32>
so: just using the text without semantic analysis
<metaleap>
for the branchings i'd just show all possibilities. if it grows unwieldy in the listings , even better for the programmer to keep the possibilities space in full view at all times
<andrewrk>
part of the reason for this proposal is the use case of IDEs/tools
<andrewrk>
that's a good approach, and the approach planned for the generated docs as well
<andrewrk>
idea is to take multiple semantic analysis dumps and merge them into one, turning scalars into arrays where applicable. as a result the generated docs js file will need to be improved to handle the extra information, but it will also allow more complete and correct docs that apply to all builds
<metaleap>
there's an idea! so the missing parts are those indicated by TODO or are there others as well?
<andrewrk>
idk I'd have to read the code myself to remember. I think it merges AST first, and primitive types. and then TODO is the rest
<andrewrk>
once primitive types are merged, you can merge structs; for example if a struct has a field that is composed only of the same primitive types in the same order, then you can easily merge that
<andrewrk>
repeat until there is nothing left to merge
<andrewrk>
I think contributing to this and to generated docs would be a really good way to become knowledegable of exactly the right things you need to know for the LSP project
marmotini_ has joined #zig
<andrewrk>
it would also put you in a good position to suggest changes to how the semantic analysis dump is structured
<metaleap>
ok i shall take a more in-depth look into this whole machinery this weekend!
marmotini_ has quit [Remote host closed the connection]
<BaroqueLarouche>
anybody know why Apple doesn't use LLD ?
frett27 has quit [Ping timeout: 255 seconds]
daex has quit [K-Lined]
_whitelogger has joined #zig
<betawaffle>
phew, thought i might have missed the start of the stream
<andrewrk>
gimme another hour to finish up what I'm working on
<betawaffle>
ok
<betawaffle>
i'm really disappointed how the #go-nuts reacted to my complaint about casting
<metaleap>
betawaffle did they go nuts .. did they show no guts?
<betawaffle>
heh
<betawaffle>
no, they though it was silly that i'd want to be able to cast from a slice of (the equivalent of) []i8 -> []u8
<betawaffle>
"really, pray tell, what will the negative values be in the unsigned type?"
<betawaffle>
or rather... they thought i should just loop over my slice instead. and that's what any other language would do under the hood, but go doesn't "hide" that from you
<betawaffle>
are you f*ing kidding me?
<fengb>
There's a lot of stockholm syndrome in Go :(
<metaleap>
well you can "dirty"-cast from one slice type to another same-sized slice type in C or zig, but i think with "unsafe" pkg you could do the same in go IIRC
<fengb>
There was massive backlash on trying to introduce Rust or Zig style try macros
<betawaffle>
metaleap: correct, you can do it with unsafe in go
<betawaffle>
*(*[]uint8)(unsafe.Pointer(&val))
<betawaffle>
but that's... even more frowned upon
<metaleap>
exactly. just the ticket. with a little "lecturing" in the pkg name :D
<andrewrk>
4550 is ready to be merged if it passes tests
<fengb>
That's how C woudl do it. Totally fine
<betawaffle>
but the problem is... they don't make you do that for int8 -> uint8
<andrewrk>
that was super weird when they rejected the `try` proposal
<shakesoda>
how dare you have the audacity to know what you expect out of numbers on a computer!
<andrewrk>
I was thinking, "interesting, they're closing the gap between go and zig. this is going to be good for them"
<betawaffle>
andrewrk: tbh, i didn't like the try proposal
<andrewrk>
wasn't it pretty much exactly zig's try?
<betawaffle>
i like try in zig, but it's different in go
<betawaffle>
no, it had quirks, because go has quirks
* shakesoda
really wants function expressions / #1717
<fengb>
Meanwhile, I do shit like `const result = Op.Fixval{ .i32 = @ptrCast(*align(4) i32, raw_result_ptr).* };`
<betawaffle>
oh yeah, no more struct { ... }.my_func
<betawaffle>
fengb: that's nice and clear, tbh
<fengb>
It's just really raw... trying to optimally reuse the memory is really playing hell with my sanity
<fengb>
Maybe I should go back to bitcasting everything to be the same size. That was a lot easier
<fengb>
I had a good idea but it's just way too complicated
<betawaffle>
i really wanted something like ^ that in Go
<fengb>
Just gonna live with up to 12 bytes of bloat per variable :(
<betawaffle>
being able to cast from a slice to an array pointer...
<betawaffle>
fengb: unions?
<fengb>
Yeah that was my first approach. Putting a u32 inside a u128 is a little heavy but it's so much cleaner
<fengb>
This was me trying to compress the memory to the correct size... but it's a lot worse than I had imagined
Sahnvour has joined #zig
<betawaffle>
i wish there was a language that could deal with arbitrary bits as nicely as erlang, that wasn't erlang
<fengb>
betawaffle: I think part of the problem of Go is that they're trying to pretend to be low level *and* app level. e.g. doing bit casting in Java would be super foreign
<betawaffle>
right
<shakesoda>
seeing that u65535 is possible in the docs had me stuck on that thought all that night
<betawaffle>
they're not app-level enough, and not low-level enough
<shakesoda>
just shove and entire c64 rom in that one variable
<shakesoda>
* an
<betawaffle>
shakesoda: too bad it's a compile error atm
<shakesoda>
well, the docs say it's valid at least :)
<fengb>
Yeah it's an implementation bug (e.g. LLVM)
<shakesoda>
fengb: re app vs low level, I really hate how some languages have made many just plain afraid of thinking about memory and bits
<shakesoda>
you're on a computer! it's a fact of life! and we know how the numbers work, too.
<fengb>
Eh... it's nice to stop worrying about bits at a low level. I don't anyone in Lisp would want to worry about translating lists into actual bits
<shakesoda>
no amount of clever vm/compiler will save a program that doesn't make any attempt to acknowledge the fact that it does, in fact, need to run on a real machine.
<fengb>
Have... you met functional programmers? 🙃
<shakesoda>
worse, I've met... oop programmers
* shakesoda
runs!
* shakesoda
runs fast!
<betawaffle>
shakesoda: this is where you'd want to run, isn't it?
<fengb>
Eh, oop gets a bad rap because people use "objects" in languages and pretend like that's the only design needed
<shakesoda>
the conventional java interpretation of oop is one of the most harmful things to have ever happened to software development
<fengb>
Yeah I don't doubt that ;)
<BaroqueLarouche>
who needs unsigned int anyway ? - Sun programmers in the 90's
<fengb>
But also... strategy pattern is useful. And languages that don't let me implement that are really annoying
<shakesoda>
I don't think every idea that gets thrown around is terrible, but oh goodness, the monsters people have learned to create in their name.
<shakesoda>
betawaffle: yes, turns out
<fengb>
Anyway... Java programmers don't generally think about memory spaces. Maybe that's a bad thing, but most of the Java work I've done has very little to do with memory layout
<fengb>
So shoving bits into the same place doesn't make as much sense as inheritance polymorphism
<betawaffle>
so that's why java is such a memory hog
<fengb>
We could get away with doing union polymorphism... but that doesn't buy a whole lot and it'd look foreign in Java
<fengb>
Nah, Java is a memory hog because it loads all the classes into memory for funsies
<fengb>
Can you imagine a language where you only load the classes that you use?
<shakesoda>
turns out, i can
<betawaffle>
i can imagine one where you don't load classes at all :P
<shakesoda>
I have a very fundamental belief that one should always have the machine on the mind when writing programs, at least a bit
<fengb>
Yeah it's every other language. But Sun decided otherwise
<fengb>
Why am I defending Java? lol
<shakesoda>
certainly not wrangling it in every single possible moment, but it should always be on the mind
<shakesoda>
down this line of thought is a lot of that I like to complain about with modern software
<metaleap>
the whole java hype 2 decades ago was something else. it was the hottest thing evarr. applets! smart fridges! tomcat servlets! oh boy, the kool-aid that was guzzled.....
<betawaffle>
it's really true
<fengb>
OTOH, we can only do so much. Enterprise software sucks, but business priorities come first
<betawaffle>
especially the part about dependencies
<fengb>
And yes, we've gotten lazy but we can't all be doing C++ every day and ship features as fast as business wants them
<fengb>
Hell, I do Javascript most of my day. I think most of it is crap, especially Electron
<fengb>
But... solving UI is hard in general. And as crappy as React is, it's less crappy than a lot of other stuff that came before it
<fengb>
(Honestly though, I actually like React. It's gotten out of my way more than every other UI framework I've used)
<BaroqueLarouche>
fengb: any experience with any desktop UI tookit ? (Qt, WinForm, MFC, GTK, etc.)
<shakesoda>
javascript has so much insanity in every corner it is unbelievable lol
<fengb>
It does... but it's also not a real problem
<shakesoda>
no, it's just an annoyance
<fengb>
Most of it wouldn't pass normal linting rules
<shakesoda>
it's weird, and then you learn that it is weird, and then you have tools that tell you you've encountered the weird again.
<shakesoda>
and then you move on
<fengb>
Michaël Larouche: hated MFC. GTK felt pretty raw and it renders ugly on non-Linux. I actually think Cocoa is one of the best designed APIs once you get over its weird architecture
<shakesoda>
I generally don't think of c++ as being a good idea for most software, everything in it is a collection of guns pointed in every direction
<shakesoda>
unfortunately, I also work in games, and c++ is incredibly common. as is being shot.
<BaroqueLarouche>
in games it's either C++ or C#
<fengb>
Let's fix that!
<BaroqueLarouche>
and shipping C# code on consoles is...."fun"
<metaleap>
fengb: "And yes, we've gotten lazy but we can't all be doing C++ every day and ship features as fast as business wants them" --> thats the narrative but what i witness in reality is that where "business" relies on nominally-simpler-than-C / GC'd stacks such as java/.net and equivs, an overall sloppier dev atmo emerges that leads to coders being really sluggish with every silly little task and introducing dumb bugs left and right. moving from all the
<metaleap>
high-level hand-holding stuff to sth like zig showed me that a tech requiring the utmost attention and discipline wrt mem & resources carries that over to the other "domain" aspects & design decisions, i think. the projects i've seen in hi-level stacks that 100s of devs laboured over endlessly yet listlessly over a decade or so.. could be leaned up so tightly if it could just be reset, but "business" would never go for it. so it goes
<shakesoda>
yeah, it's a bit hard to avoid c++ (or c#) in games when you aren't flying solo
metaleap has quit [Quit: Leaving]
<shakesoda>
i will say though, it's very likely the low level bits of my in-house engine will be moved to zig sooner than later (from c and a sprinkle of c++)
<fengb>
metaleap: sure I agree but I don't think we'd have 10% of our large developer ecosystem if we stuck with older non-GC systems
<fengb>
And we can argue how useful most of it is... but it pays the bills
<shakesoda>
i have little concerns for anything but my own needs with it, and zig doesn't also force me to go all-in just to get things working, so it's a very much viable option
<shakesoda>
the high level/game code is all haxe->lua, which I'm already fairly happy with
<fengb>
I'm also not a game dev. I've heard... rants from Jon Blow and he'd probably hate my guts if he met me >_>
<shakesoda>
uh I am not sure I'd worry too much about his opinion specifically
<shakesoda>
he's a smart guy and all, just with a lot of burning hot takes
<shakesoda>
i'm not sure if i'd get along with him either. maybe.
<fengb>
Oh yeah. But I do sense a degree of smug from a lot of game devs. I can understand the resentment... but I really couldn't care about my data layout when I'm dealing with concurrency issues because users click on random things
<fengb>
Most of my hard problems are because browsers suck or concurrency crap I can't control
<fengb>
Anyway... I think I digressed enough
<shakesoda>
well, when at all possible you should always care about basic performance properties - at least in so far as to not obviously do things in the worst ways
<jaredmm>
Eh, it all matters. We stack inefficient software on top of inefficient software repeat for multiple layers and then try to find ways to make things passibly fast.
<shakesoda>
yeah, that's the thing there
<shakesoda>
bad performance in anything compounds, in all the software you use and build
<shakesoda>
does everything need to be as fast as is humanly possible? no - but it shouldn't be *too* much slower than it needs to be, either
wootehfoot has quit [Ping timeout: 265 seconds]
<shakesoda>
gamedevs are particularly sensitive to this, because our entire lives are measured in small numbers of milliseconds :)
<jaredmm>
I mean, most game devs aren't great, either. They're the same as everyone else, trying to get a job done. You typically have one or two guys that are focused on trying to set people up to succeed, but then you let everyone else into it and oops, they've got deadlines.
<shakesoda>
game devs are a broad category, too, lots of very different work
<betawaffle>
shakesoda: what games do you work on?
<betawaffle>
andrewrk: your hour is up
<jaredmm>
As a profession, I think we set ourselves up for failure in a lot of ways. No one understands hardware, everything is hard, and everyone wants the world.
<betawaffle>
hardware is surprisingly complicated
<shakesoda>
betawaffle: recent projects nda, past highlights include skullgirls, stepmaniax, various indie games that have needed better render performance or porting (and, sometimes, 3d models)
<fengb>
Also the free lunch is up. We can no longer just throw hardware at problems
<jaredmm>
I understand why there's people raging against the machine, but for the majority of the work that we do, the cost of the development is visible while the cost of doing that development wrong is amortized over a very long time and written off by the next guy to come in as "the old guard didn't know what they were doing".
<fengb>
Software engineer: coasting on the shoulders of hardware engineers since 1950
<betawaffle>
fengb: but we are... we're just throwing *more* hardware at it, rather than better hardware
<Sahnvour>
jaredmm: gamedev is crippled by tight schedules and bad management usually though, people outside of specialists just don't have the time to learn this stuff because you gotta get that new feature for the next milestone
<shakesoda>
hardware is indeed complicated but the most needed work for making things run well is the basics, not the intimate details.
<fengb>
betawaffle: it actually requires rethinking and redesign now. In the golden day we literally did nothing but wait a few years, but now we gotta account for parallelizability
<shakesoda>
the stuff that costs very little time and fairly minimal knowledge to do as you go
<jaredmm>
Sahnvour: you can replace gamedev with every industry, but I agree.
<Sahnvour>
sure
<betawaffle>
i still can't figure out why Go has native complex number types
<jaredmm>
On Blow specifically, he's just saying a lot of things that build up after dealing with all the problems with development. He made enough money that he was able to indulge in some grand ideas for change. I'd be interested in seeing if his opinion changes the deeper into it he gets.
<betawaffle>
like, it would make sense if it had more than only complex numbers...
<betawaffle>
but that's the only "weird" built-in type it has
<fengb>
I think most of the reasoning behind Go can be summed up with "because word-of-god wanted it"
<jaredmm>
When it is your money burning away every month, you quickly realize why a lot of the inefficiencies exist. It isn't a great choice, but saving money now vs. potentially losing some in the future due to maintenance costs (or if you're some companies, continuing to charge to fix problems you made in the first place).
dhawkie has joined #zig
<shakesoda>
jaredmm: ye olden technical debt, acceptable costs etc
<betawaffle>
i think zig needs complex numbers, quaternions, decimal fixed-point numbers, rationals, matrices, etc.
<shakesoda>
betawaffle: except for complex numbers these would all be very useful to me, and I completely disagree :D
<jaredmm>
I'm working on rewriting an application right now because of requirement changes and technical debt that has created security issues, looking at 10 year old TODOs.
<betawaffle>
shakesoda: you use quaternions a lot i bet
<shakesoda>
I do, actually.
<betawaffle>
aren't they just a 4-dimensional version of complex numbers?
<shakesoda>
hmm, that's a reasonable way to describe them
<shakesoda>
jaredmm: one of the games I work on has amassed about 20 years of technical debt, and some brave souls have finally put in the work to kill a lot of it in this last year
<shakesoda>
it is a wonderful thing.
<betawaffle>
anyway... that sort of proves that *sometimes* limited forms of operator overloading can be really useful
<betawaffle>
i like the way that haskell does it
<betawaffle>
you can define whatever the fuck operators you want
<betawaffle>
:=- can be an operator
<companion_cube>
:-/ can be one too
<shakesoda>
this is the case where operator overloading is useful, but it's also not so big of a loss to not have it in my experience
<shakesoda>
operator overloading hides *TONS* of really nasty costs
<betawaffle>
fair enough
<jaredmm>
Principle of least surprise and all that leads me to prefer a language that can be expressive without overloading. Symbols don't immediately make me think about everything that could be going on behind them, especially when overloaded.
wootehfoot has joined #zig
<shakesoda>
yeah, exactly, not having that concern is something I've been liking about zig
<jaredmm>
When you work with a lot of people who will try to write `genius` code for everything, it gets tiresome trying to keep that unique context in your head per application while a function call is an obvious sign that I need to see what the function does.
<betawaffle>
i suppose a reasonable stance to take would be every operator has to map to a single instruction, generally
<shakesoda>
I can see quite clearly the full extent of what I am dealing with, by what it says.
<fengb>
Not all instructions are the same speed 🙃
<shakesoda>
jaredmm: that has been a very real and severe issue in... most... of the c++ codebases I've ever had the misfortune to work on
<betawaffle>
let me ask a probably silly question... why do we allow operators at all? why not only function calls?
<fengb>
andrewrk has (facetiously?) threatened to take out operators before
<betawaffle>
stream when?
<betawaffle>
my only problem with function calls is paren soup
<fengb>
I'd argue that if we get rid of operators, we might as well move towards Lisp syntax
<shakesoda>
betawaffle: for the basic types where the ops quite reasonably map to basic cpu instructions on every machine, 1 + 1 will involve no surprises
<shakesoda>
meanwhile a * b hiding a matrix mult and who knows what else, could be a very big and expensive surprise in the wrong place.
<betawaffle>
except that we know that's not true shakesoda...
<betawaffle>
just think of overflows, wrapping, saturating
<betawaffle>
it all gets very complicated and non-obvious
<shakesoda>
zig watches out for such things :)
<Snektron>
<BaroqueLarouche "who needs unsigned int anyway ? "> - also soustroup, 2019
<betawaffle>
i would like to see saturating arithmetic
<fengb>
Well in Zig, we have illegal checked behavior when things get non-obvious
<fengb>
And force you to make a decision. I actually think this is a very nice solution
<shakesoda>
I think this also encourages taking simpler approaches
<betawaffle>
i like being forced to make a decision
<fengb>
Sometimes it gets annoying... like `i64 - u8`... I know why I want to do damnit
<shakesoda>
the language encouraging good behavior is very much desirable
wootehfoot has quit [Ping timeout: 258 seconds]
<betawaffle>
what i don't like is that i can't put methods on non-struct types!
<shakesoda>
can't you also put them on enums?
<betawaffle>
yeah, but that's not enough
<dhawkie>
hi guys. really excited about starting a new project in Zig, using C interop. but I am having trouble from the get-go. I am statically linking to a c library. the library has a huge struct with over 100 complex fields. it also has functions that act on that struct. there is a function in the library that takes the struct and initializes the
<dhawkie>
contents. but to create and pass that struct(from cImport->cInclude) from Zig I have to fill all the fields first.. how can I bypass this and provide a struct/something to the library to act on? i tried to create a c wrapper to create the uninitialized struct, but ran into other issues. maybe there's a simpler way... thanks for any help!
<betawaffle>
i want too put them on floats, and i want native flag types
<betawaffle>
too...
<fengb>
dhawkie: you can define an uninitialized variable with `var foo: Type = undefined;`
<fengb>
Or zero it out with `var foo = std.mem.zeroes(Type);`
wootehfoot has joined #zig
<dhawkie>
aah, "undefined", i saw that somewhere but had forgotten it. thanks, i'll try it
<daurnimator>
dhawkie: ask yourself: what do you *want* those fields to be?
<dhawkie>
whatever basically, they will get overwritten anyway
<daurnimator>
dhawkie: either they need to be initialised to some special value; or they can be undefined; or the C library assumes 0 initialisation (which would be treacherous for different variable types...)
<daurnimator>
dhawkie: ah right: yeah you could be searching for the pattern: `var foo: Type = undefined; if (mylib.initmything(&foo) != mylib.code_okay) return error.FailedToInitialise;`
<betawaffle>
is an inline for with ifs ultimately the same as a switch?
<betawaffle>
do switches ever turn into something more efficient?
<betawaffle>
like a binary search, or jump table?
<fengb>
LLVM will probably optimize them both into a jump table
wootehfoot has quit [Ping timeout: 260 seconds]
<betawaffle>
both?
<betawaffle>
interesting
<daurnimator>
betawaffle: switches often turn into jump tables; `if` tends to turn into branches
<fengb>
Switch definitely, inline if it recognizes it
<daurnimator>
betawaffle: though LLVM may optimise things....
<betawaffle>
i guess i'm too used to Go's level of optimization
<fengb>
I think doing simple `if (same_var == foo)` or slightly complex `if (mem.eql(u8, same_var, "foo"))` works fine, but no guarantees
<shakesoda>
zig spares me from worrying about a lot of the more trivial optimizations and I appreciate that greatly
<betawaffle>
the reason i ask is you can't build a switch at comptime, but you can do an inline for with all comptime-known values
<fengb>
Ah yeah, I kinda want to make a proposal for generating a switch
<daurnimator>
andrewrk: did you ever give git-bug a try?
<betawaffle>
when the zig package manager stuff is done, i hope most of std can be turned into completely optional and replaceable packages
<companion_cube>
beware of the npm effect
<daurnimator>
betawaffle: yes the intention is to split a lot out. However we also want the package manager itself to be implemented with the standard library
<betawaffle>
yeah, well we need to figure that out too, because it's real... npm, rust, and go all have that problem at least
<fengb>
I'm still hoping we can have a defacto curation system going
<andrewrk>
dependency proliferation is a problem in the sense that bugs in software are a problem
<companion_cube>
I think the stdlib at least needs a good set of containers, json, and some IO
<daurnimator>
companion_cube: e.g. why json?
<andrewrk>
give someone a programming language, and they will create bugs
<andrewrk>
give someone package management, and they will create dependency proliferation
dimenus has joined #zig
<companion_cube>
daurnimator: so taht everyone agrees on the type and can use it without questions
<andrewrk>
the solution is the same: better tooling to help guide programmers to prevent problems
<fengb>
andrewrk: not always true. Ruby tends to feature a core of a few common gems because the community gelled around them
<betawaffle>
right, so what tooling can help the package management problem?
<companion_cube>
steam achievements when you remove dependencies
<fengb>
npm ecosystem decides on a whim, so you end up with duplicates of everything
<daurnimator>
fengb: on the other hand, in lua that centralisation/agreement never happended, so you have 10 different libraries for arrays...
<betawaffle>
go was doing pretty well until modules
<fengb>
Right, I feel like it's a solvable `*social*` problem, but definitely not solved by most ecosystems
<companion_cube>
I'd say that standardizing at least *types*/interfaces is good
<betawaffle>
it's almost as if the easier it is to depend on things, the more people will depend on...
<companion_cube>
then you can still have libraries making various choices for implementation
<companion_cube>
(see `future` in rust)
<daurnimator>
betawaffle: there was a saying in python: "the standard library is where modules go to die"
<companion_cube>
and yet, the stdlib is what makes python so convenient ootb
<companion_cube>
for scripting and such
<betawaffle>
companion_cube: i do like the idea of standardizing interfaces
<betawaffle>
speaking of interfaces...
<fengb>
Maybe we can have a distributed stdlib...
<companion_cube>
imagine if your io reader interface is not common… 😱
dhawkie has quit [Quit: dhawkie]
<daurnimator>
companion_cube: sort of... when I write robust python I always end up having to swap out stdlib modules
<frmdstryr>
Just jumped on, if you're talking about package managers I'd highly recommend looking at how conda does it
<betawaffle>
companion_cube: tbh, that's the problem i have in zig right now
<companion_cube>
heh, I wouldn't write robust python, just small scripts :p
<betawaffle>
i don't get streams yet
<fengb>
Oh boy... yet another Python package manager? :P
<frmdstryr>
conda is robust because every package build is done in a completely new env
<betawaffle>
can we learn from nix somehow?
<daurnimator>
frmdstryr: zig packages are going to be source-only to start with
<companion_cube>
can nix learn to not want to own the whole system? :p
<betawaffle>
companion_cube: that's kinda my problem with it still
<betawaffle>
i'm on a mac, and it's not trivial to make it happy on latest OS version
<fengb>
Oh yeah, Catalina removed support to write to /nix
<betawaffle>
you can make it work, but it's high-touch
dhawkie has joined #zig
<betawaffle>
andrewrk: stream never?
<frmdstryr>
daurnimator: How does that work if it has external c/c++ deps?
<daurnimator>
frmdstryr: great question. I've thought it through that build.zig should contains declarations like external dependencies and other misc configuration.... but maybe that should be in an easier-to-parse-for-others format
<daurnimator>
fengb: did you get anywhere with moving std.fmt to streams?
<fengb>
Nah, I haven't looked yet
<frmdstryr>
conda solves it by building specific libs, eg Qt and bundling it as a package so you can specify and build against specific versions
<frmdstryr>
it's pretty much like debian but "app" level instead of os level
<fengb>
I think one of the goals is to make C/C++ shippable in Zig packager
<frmdstryr>
yeah that's the proper way, then it can all be bundled into an installer easily as well
<andrewrk>
betawaffle, I wanted to show off the latest changes regarding os versions as part of target info, and I didn't get it done in time, so I'm going to postpone to tomorrow
<dimenus>
andrewrk: i'm reviewing your changes in the os-version-ranges branch and I'm a bit confused as to how glibc versions fit into the new system. If I specify a glibc version, should that generate a non-native targeT?
<andrewrk>
dimenus, an important new feature of this branch is granularity into specifying what exactly about a target is native and what is not
<andrewrk>
for example, one can do this now: -target native-native-gnu.2.10
<andrewrk>
one will get a fully native target, except with an overridden glibc version
<andrewrk>
another interesting example would be (on linux): -target native-windows
<andrewrk>
or in the WSL: -target native-linux
<andrewrk>
in the former case you could run an executable in Wine with native CPU features; in the latter case a linux executable on windows with native CPU features
<dimenus>
andrewrk: that's what i expected actually - but it doesn't seem to function correctly yet
<andrewrk>
in the branch?
<dimenus>
yep
<andrewrk>
which example?
wootehfoot has joined #zig
<dimenus>
i'm just calling 'setGnuLibCVersion' in my build.zig
<dimenus>
that emits a regular native target instead of the one you defined above
<andrewrk>
that function doesn't exist in this branch
<andrewrk>
that data is specified as part of the target now
frmdstryr has quit [Read error: Connection reset by peer]