<mikdusan>
it looks odd to return stack but in comptime that works
<marler8997_>
thanks
marijnfs_ has joined #zig
<st4ll1>
shakesoda: oh i did not finish my question yesterday, yeah i upgraded zig to 0.6.0, so do i know need to rewrite my c.<ENUM_value> to c.<ENUM_name>.<ENUM_value> or something like that am i right?
<shakesoda>
st4ll1: you can infer them with just an unqualified . also
TheLemonMan has joined #zig
<shakesoda>
c.whatever will exist but have an int type, not enum value type
<ikskuh>
i cannot find the word "tree" on that page :D
<ikskuh>
that's why i'm asking
<ikskuh>
i know what SSA itself is
<alexnask>
Ah mb I misunderstood :)
<ikskuh>
but nice to see that zig slowly gets into self-hosted direction
<ikskuh>
would be funny if the zig self hosted compiler could beat Go in terms of compile times for unoptimized code :D
<alexnask>
We should make a C->zir frontend to dethrone C as soon as possible too :-P
<ikskuh>
haha that would be rad
<ikskuh>
yeah, btw. our C compiler is faster than yours :D
<ikskuh>
but first: make it work for Zig
metaleap has quit [Quit: Leaving]
TheLemonMan has quit [Ping timeout: 256 seconds]
cren has joined #zig
Xavi92 has joined #zig
<Xavi92>
Hi, is it possible to specify endianness on a packed struct?
<fengb>
Nope they’re always native
<fengb>
ikskuh: our target should be V. 1 *million* lines in <1s :P
<Xavi92>
fengb: hm, do you think it would be a reasonable proposal to the language? I think it could be useful on many situations e.g: when dealing with a protocol where endianness is fixed such as Bluetooth
<fengb>
I think that was recently rejected
<Xavi92>
fengb: something like `const Packet = packed struct big endian { ... }`
<fengb>
I do agree though. My emulator relies on little endian
<Xavi92>
fengb: many protocols and file formats do. Status quo would require handling these situations manually (at compile-time in the best case) while that's something the compiler could handle easily
<daurnimator>
fengb: yeah I'm seeing results both ways
<alexnask>
Let's just make an OCR and a scraper to settle this /s
<fengb>
Well the US post office will go bankrupt soon so we can start from scratch!
foobles has joined #zig
waleee-cl has joined #zig
TheLemonMan has joined #zig
metaleap has joined #zig
<Xavi92>
ikskuh: sorry, was afk
<Xavi92>
ikskuh: the deserializer library looks cool
<cren>
Hey all. I'm learning Zig. What's the accepted way to do what in other languages would be done by a for-loop over a range of numbers (like `for (int i=0; i < n; i++)` in C)? I was assuming a while loop but I want to make sure.
<betawaffle>
probably a for loop
<ikskuh>
iit's the while loop
<betawaffle>
oh right
<alexnask>
var i: usize = 0; while(i < n) : (i += 1) { ... }
<ikskuh>
var i : usize = 0; while(i < limit) : (i += 1) { }
<cren>
why is `i` type `usize`?
<cren>
oh wait
<cren>
I get it
<cren>
nvm
<cren>
actually, no, I don't get it. Why is `i` type `usize`? Why not just use `u8` or something?
<fengb>
usize is most "natural" for indexing into an array, but you can use any size you want: u8, u32, u64, etc.
<fengb>
usize == ptrsize. It's what the CPU uses under the covers for dealing with memory
<fengb>
But you can choose any size that's large enough and it should be fine
<cren>
does that mean that the size of `usize` varies with CPU architecture?
<fengb>
Yes
<ikskuh>
i still think we should split up usize into two types…
<ikskuh>
i wonder if i should make a proposal for that…
<ikskuh>
especially when we now leave the lands of llvm code gen
<TheLemonMan>
two types?
<Snektron>
In which two
<fengb>
What, like reg size and ptr size for Z80?
<Snektron>
Those are equal
<ikskuh>
usize → size of the largest adressable object
<ikskuh>
uptr → size of a pointer
<ikskuh>
Snektron: ptr on z80 is 16 bit, reg is 8 bit
<ikskuh>
but:
<Xavi92>
usize (as size_t in C) is what should be used in loops and array indeces to avoid potential problems
<fengb>
Not exactly... u8 is more "natural" in Z80
<ikskuh>
ptr on AVR is 24 bit, largest object is 16 bit and register is 8 bit
<Snektron>
The bus is 8 bit afaik
<ikskuh>
Xavi92: size_t is not usize!
<Xavi92>
ikskuh: what is it then?
<ikskuh>
uintptr_t
<ikskuh>
both AVR-GCC and LLVM fuck up AVR adressing
<ikskuh>
because you have three memory spaces
dimenus has joined #zig
<ikskuh>
two of which are 16 bit large (which is the pointer size used in LLVM/AVR-GCC) and one which is 24 bit
<Snektron>
<ikskuh "ptr on AVR is 24 bit, largest ob"> Maybe this should be combined with other far-ptr mechanics
<ikskuh>
it isn't a far ptr
<ikskuh>
you cannot have a pointer to data in flash behind 64k border in AVR-GCC
<TheLemonMan>
well you have addressspace() there
<ikskuh>
same goes for functions
<ikskuh>
even if you have functions in the space beyond 64k, AVR-GCC will insert a shim
<ikskuh>
that just does a jump to the actual address
<TheLemonMan>
having three pointer different types for each space makes little or no sense
<ikskuh>
TheLemonMan: yeah, i know that we have addressspace()
<fengb>
How do you index beyond 64k? Is there a separate instruction for load high?
<ikskuh>
i just want that we change the definition from usize to actually match the definition of size_t, not intptr_t
<TheLemonMan>
but then the usize <- ptrtoint mapping falls apart
<alexnask>
Okay, I will switch to using the ast node, I just saw some other code that checked the body of the entry but it isn't necessary in this case.
alexnask_ has joined #zig
alexnask has quit [Ping timeout: 260 seconds]
alexnask_ is now known as alexnask
<dimenus>
andrewrk: I think I have my bug narrowed down from the other day on my PiOS. It looks like pointer addresses are not calculated correctly in a debug build of a flat binary
<dimenus>
eg the kernel in the raspi is loaded at 0x80000, but the .ptr of a slice points to an address below that
<dimenus>
only happens in debug build
<TheLemonMan>
debug build of a flat binary?
<dimenus>
sorry, compiling with default release options
<layneson>
what is the correct method for changing the install location/path prefix in build.zig? setInstallPrefix is not supposed to be used, but resolveInstallPrefix either installs things to zig-cache or involves install_prefix (which we aren't supposed to set)
riba has quit [Ping timeout: 260 seconds]
riba has joined #zig
<ikskuh>
TheLemonMan: i added my response to the original proposal as pro/con discussion
<TheLemonMan>
ikskuh, so on AVR you'd define usize = u16 and uptr (or upointer or whatever) = u24 ?
<ikskuh>
yep
<TheLemonMan>
cool, I agree with the proposal as well
<ikskuh>
👍
<Xavi92>
Have to go. See you!
Xavi92 has quit [Remote host closed the connection]
<ikskuh>
also, using upointer/usize makes more clear what the integer represents :)
<layneson>
oh nevermind, found --prefix
<TheLemonMan>
I'd add one more constraint to be extremely pedantic, usize <= upointer
riba has quit [Ping timeout: 240 seconds]
<ikskuh>
i think that's actually intrinsic
<ikskuh>
because you cannot have larger objects than number of bytes :D
<ikskuh>
*number of adressable bytes*
<TheLemonMan>
yeah but when writing a spec you want to be extra precise
<TheLemonMan>
that means you can safely add upointers and usizes
<TheLemonMan>
and the pointer arithmetic is sound
cren has quit [Remote host closed the connection]
<TheLemonMan>
last time I checked the stdlib made a lot of assumptions about usize, namely that it's somehow related to the registers size
<TheLemonMan>
that was a major hurdle when trying to port it to the x32 ABI
<ikskuh>
yeah i can imagine that
<ikskuh>
maybe add something like uregister as well?
<ikskuh>
a type that can safely be stored in a single register
<ikskuh>
don't know though, sounds dangerous to me (as 8 bit is really not that much)
<TheLemonMan>
maybe that's stuff for std.builtin.types.register or something like that
<ikskuh>
yeah
<fengb>
Well... register is a bit ambiguous too >_>
<ikskuh>
yeah, true
<fengb>
Let's call it a "word". Not confusing at all 🙃
<ikskuh>
oh yeah ♥
<ikskuh>
let's do all the words
<TheLemonMan>
{,d,q}word
<alexnask>
word, dword then eventually stop making sense entirely by making dword32 and dword64 independent from the word size
<fengb>
oword?
<ikskuh>
hword!
<ikskuh>
which is 4 bit on z80
<fengb>
I've been calling that a nibble
<TheLemonMan>
SPARC assembler also supports ... nword
<ikskuh>
fengb, yeah nibble is the right term for 4 bit
<ikskuh>
byte is actually also defined as smallest machine unit (at least to an ancient IBM handbook which defined the word)
<ikskuh>
and octet is the correct thing for 8 bit integer :D
<fengb>
Wait, so byte didn't necessarily mean 8 bits?
<pixelherodev>
It does *now*
<ikskuh>
yep, it does *now*
<ikskuh>
but no, it wasn't 8 bit, there were also machines that had 6 bit wide bytes
<ikskuh>
i think the original def even had something more weird :D
<alexnask>
5 bit is the best system
<ikskuh>
19!
<fengb>
If we can't represent PDP7, what chance to we have to kill C?
cole-h has joined #zig
<alexnask>
Also, no bi-quinary :(
<pixelherodev>
Obviously we need to be able to represent *trinary* systems!!!
<pixelherodev>
Not just *bits*, but *trits!*
<pixelherodev>
Okay there's definitely a better name for those
<pixelherodev>
trines?
<pixelherodev>
Okay but now I'm seriously tempted to write an emulator for a CPU using trines
<fengb>
True, False, FileNotFound
return0e has joined #zig
<alexnask>
0, 1, 2 or 0, 1/2, 1?
<pixelherodev>
Former, probably
<companion_cube>
didn't USSR people have ternary computers at some point?
mattmurr has quit [Ping timeout: 256 seconds]
<ifreund>
why
<fengb>
It's more natural as -1, 0, 1 from a physical standpoint
<fengb>
Negative voltage is a lot easier to detect than half voltage
<alexnask>
Huh, seems like they made Setun (ternary computer) in 1958
st4ll11 has joined #zig
<fengb>
-5V, 0, 5V is a simpler construct than 0, 5V, 10V. Not sure it's worth it though since it's still much harder than simple 0 -> 5V
<alexnask>
@fengb, Right I'm just talking about what the trines represent :D
<fengb>
We should use phase offsets instead
<pixelherodev>
huh
<pixelherodev>
"he first modern, electronic ternary computer, Setun, was built in 1958 in the Soviet Union at the Moscow State University by Nikolay Brusentsov,[4][5] and it had notable advantages over the binary computers that eventually replaced it, such as lower electricity consumption and lower production cost.[4]"
<pixelherodev>
s/he/The
<pixelherodev>
Okay so I know what project seven of Lightzing will be
<pixelherodev>
Balanced ternary emulator :P
<pixelherodev>
Oh wow
<pixelherodev>
Samsung is funding development of an unbalanced ternary system in South Korea, apparently
<alexnask>
lol
<ikskuh>
<pixelherodev> Not just *bits*, but *trits!*
<ikskuh>
someone built a logic gate based on three-bit floating point arithmetic
<alexnask>
what about trips?
layneson has quit [*.net *.split]
frett27 has quit [*.net *.split]
nephele has quit [*.net *.split]
st4ll1 has quit [*.net *.split]
knebulae has quit [*.net *.split]
return0e_ has quit [*.net *.split]
Winterfury has quit [*.net *.split]
bkleiner has quit [*.net *.split]
so has quit [*.net *.split]
oats has quit [*.net *.split]
jaredmm_ has quit [*.net *.split]
Nilium has quit [*.net *.split]
<fengb>
twits?
<alexnask>
triads
<pixelherodev>
Trees
<pixelherodev>
I do like "twits" as a descriptor though
mattmurr has joined #zig
<pixelherodev>
Ugh, apparently trits is the commonly used one
dimenus has quit [Read error: Connection reset by peer]
<pixelherodev>
(Misleading names)
marijnfs_ has quit [Ping timeout: 244 seconds]
layneson has quit [Ping timeout: 246 seconds]
<ifreund>
ah i meant the titmouse which is the best tit
marijnfs_ has joined #zig
a_chou has joined #zig
a_chou has joined #zig
Akuli has joined #zig
a_chou has quit [Quit: a_chou]
mattmurr has quit [Ping timeout: 256 seconds]
marijnfs1 has joined #zig
cren has joined #zig
marijnfs1 has quit [Client Quit]
<cren>
Hello. I'm learning Zig. Is there a way to pass an array of an unknown number of items to a function? I mean what you would do in C by passing a pointer to the first element of the array
<ifreund>
cren: you want a slice most likely
<ifreund>
(which is a pointer + a length internally)
<pixelherodev>
Slice == array imp'd
<pixelherodev>
:P
Akuli has quit [*.net *.split]
so has quit [*.net *.split]
Winterfury has quit [*.net *.split]
bkleiner has quit [*.net *.split]
jaredmm_ has quit [*.net *.split]
oats has quit [*.net *.split]
Nilium has quit [*.net *.split]
marijnfs_ has quit [*.net *.split]
frett27 has quit [*.net *.split]
nephele has quit [*.net *.split]
knebulae has quit [*.net *.split]
<cren>
that sounds about right
<cren>
let me look at the docs
<alexnask>
[]T <- slice, []const T <- const slice
<ifreund>
and a pointer to an array coerces to a slice
<pixelherodev>
Not going to explain what a []align(rand()) linksection(".totallylegit") T is?
<pixelherodev>
;)
Nilium has joined #zig
jaredmm_ has joined #zig
Akuli has joined #zig
Winterfury has joined #zig
so has joined #zig
oats has joined #zig
bkleiner has joined #zig
nephele has joined #zig
knebulae has joined #zig
frett27 has joined #zig
<alexnask>
You need a phd to understand all array types in zig /s
<andrewrk>
cren, a pointer to unknown number of items is: [*]T
<andrewrk>
pointer to runtime known number of items is: []T
so has quit [Ping timeout: 264 seconds]
<pixelherodev>
alexnask, or a *phd*... eh? eh?
<alexnask>
[*:p]align(h) d
<pixelherodev>
I meant pixelherodev == phd ;)
<alexnask>
lol
<foobles>
ok so rust has rustic, python has pythonic,
<foobles>
ziggish?
<pixelherodev>
ziggy?
<companion_cube>
ziggity
<foobles>
nice
<pixelherodev>
Z'ur'gah
<pixelherodev>
You're not using enough hyphens/apostrophes :P
<pixelherodev>
Z'gt'y
<pixelherodev>
s/g/g-/
xackus has joined #zig
<TheLemonMan>
zigalicious
so has joined #zig
<alexnask>
zidiomatic
<pixelherodev>
zigiomatic?
<pixelherodev>
Zigantic
andy_bainbridge has joined #zig
cren has quit [Remote host closed the connection]
sanaris has joined #zig
<sanaris>
Guys, what are your thoughts on Vlang? Sounds like the claims are little exaggerated
<companion_cube>
ever so slightly
<sanaris>
Also I compiled their language with itself and it doesnt equal to itself
<sanaris>
the binaries differ somoehow
<sanaris>
I opened the binary codes and the codes are changing like "8C" -> "8D"
<fengb>
But it compiles itself in <1s!
<companion_cube>
but it delegates all the compilation work to clang in <1s !
<sanaris>
well people write quines in any language, doesn't make it a language
<sanaris>
The binaries look ridiculous!
<sanaris>
There is just graveyards of data which is not used anyhow
<foobles>
i heard they recently started using an AST
<fengb>
Implementation detail. It iterates in one direction and will start clobbering data if there's bad overlap
<fengb>
There's a separate copyBackwards if you need to enable overlaps in the reverse direction
<andrewrk>
do we have a mem copy that doesn't have that requirement yet?
<fengb>
We could probably detect overlap and pick one of them
<andrewrk>
std.mem.copyBackwards I suppose
<andy_bainbridge>
So "dest.ptr must be <= src.ptr" is only true if there's an overlap?
<fengb>
I thought there was a PR to merge the two
<andrewrk>
andy_bainbridge, yes I think those docs are wrong
<andrewrk>
andy_bainbridge, since copying bytes is so common, there is a benefit to knowing if you can supply additional constraints, such as non aliasing or conditional aliasing as you noted
<andrewrk>
there's an issue open for this, these functions are not in their final form
<shakesoda>
my zig vulkan rendering adventure has gotten up to "i have all the basics except textures"
<shakesoda>
once i've got those i can start shaping this into the needs of my actual render api
<andrewrk>
andy_bainbridge, the only reason this isn't already fixed is that I want to make sure std.mem.copy continues to work in comptime code
<andrewrk>
oh! the lazy values mechanism provides a solution to this
<shakesoda>
andrewrk: zig-vulkan-triangle was very, very helpful for getting started with
<andrewrk>
you can thank vulkan-tutorial.com for that. All I did is port it to zig
<sanaris>
Why are people so obsessed with things being immutable everywhere
<shakesoda>
immutable data flows simpler
<andrewrk>
shakesoda, btw I'm planning to add SPIR-V support to the self-hosted backend, so that project would not need a dependency on glslc :)
<andrewrk>
lritter of Scopes has already pioneered this and I am following his lead
<shakesoda>
shaders in zig...
<shakesoda>
mind blown
<fengb>
Wow
<Nypsie>
So you write the glsl inside Zig itself and during compilation it will be compiled to SPIR-V?
<andrewrk>
yes
<Nypsie>
Oooh that's sweeeeet, I might rewrite my engine from Go to Zig soon then
<shakesoda>
how will that work for dealing with the shader-isms (uniform blocks, samplers etc)
<andrewrk>
this is the same question as how to deal with memory allocation in wasm and a few other things. probably the answer will be architecture-specific builtins
<shakesoda>
makes sense
<andrewrk>
unless there is some kind of ABI, in which case zig can already model it
<andrewrk>
lots of questions there, and I have *some* graphics background but not much, would definitely benefit from any experienced community members weighing in
<TheLemonMan>
speaking of builtins, what do you think of hiding them all into some struct such as std.builtin.<sumthing> ?
<shakesoda>
i've got a lot of experience in graphics (this is my day job) although i know little about things like spir-v abi
<andrewrk>
TheLemonMan, I'm open to this idea, but what does that accomplish?
<shakesoda>
i've had moving things to vulkan on my list for a while, since the writing is on the wall for opengl
<pixelherodev>
OpenGL over Vulkan will probably be around for as long as Vulkan is
<pixelherodev>
But that's probably smart
<TheLemonMan>
andrewrk, less clutter, the builtins list is quite long and includes useful type-level functions (@as, @ptrCast, ...), low-level intrinsics (@intToPtr, @ptrToInt, ...) and hopefully-hardware-accelerated-ops (@sin, @cos, ...). I'd say we tidy up this by moving the last category into a neat namespace and lighten the builtins list
<andrewrk>
I do want to note that while some builtins have function semantics, some have entirely different semantics. For example @field and @bitCast participate in result location semantics, and @cImport evaluates an expression in a special way
<andrewrk>
I think it would be nice to evaluate this proposal closer to the end of language stabilization, when the list of builtins is otherwise complete or near complete
frett27_ has joined #zig
<andrewrk>
currently builtins are a really nice tool for iterating on the language, since they allow arbitrary semantics without deciding on a particular syntax
<andrewrk>
e.g. maybe @Vector will gain syntax for specifying vector types
<shakesoda>
pixelherodev: i'm also interested in the efficiency gains
<shakesoda>
opengl over vulkan isn't mature enough anyways
<shakesoda>
besides, native opengl drivers are really cursed, and this is an opportunity to rid myself of the curse
<pixelherodev>
True
<pixelherodev>
Well, Intel's OpenGL drivers are good
<shakesoda>
no, uh
<TheLemonMan>
neither @field nor @bitCast nor @cImport are affected
<pixelherodev>
Intel Iris driver == <3
<shakesoda>
all opengl drivers are differently bad
<pixelherodev>
Name one problem with Iris
<shakesoda>
atomics are really sketchy in compute on there
<shakesoda>
had a hell of a time with my lighting system on there because it's quirky
frett27 has quit [Ping timeout: 246 seconds]
<pixelherodev>
With Iris? Not with i965?
<pixelherodev>
HUh
<pixelherodev>
s/U/u
<shakesoda>
oh, yeah, i was using i965 and thinking about the iris gpus
andy_bainbridge has quit [Ping timeout: 256 seconds]
<shakesoda>
but this might be resolved by now, unsure. over on windows and mac things are unendingly cursed too though
<pixelherodev>
I'm talking about the driver, not the GPU
<pixelherodev>
It's Intel's fault for the naming though :P
<shakesoda>
i have no freaking clue how some of the horrifying things that happen can happen in the crash logs i get
<pixelherodev>
Oh wait *I* can name a problem
<pixelherodev>
Run *anything* that uses a GPU through valgrind
<pixelherodev>
It's *terrifying*
<pixelherodev>
Memory errors galore!
<foobles>
crazy idea: i want my own IrInstGen object to contain a new basic block with some number of instructions, which i will then render when I render my own instruction
<shakesoda>
yeah i965 is really bad about that too
<shakesoda>
i have a valgrind config with so very many things ignored in driver land
<foobles>
what if i temporarily swap out the ira's current_basic_block, run analysis so that it puts instructions into my own struct, and then switch it back
<pixelherodev>
You can do that???
<pixelherodev>
shakesoda, link me *please*
<shakesoda>
hmmm, i don't have it on git
<shakesoda>
i'd have to go digging
<andrewrk>
TheLemonMan, can you do a proposal issue? it's definitely worth considering
<shakesoda>
but yes, you can ignore sources of things
<TheLemonMan>
sure thing, I'll write it tomorrow
<ifreund>
shouldn't it be just build.thing not std.builtin.thing?
<ifreund>
*builtin
<shakesoda>
pixelherodev: look up valgrind suppressions
<TheLemonMan>
ifreund, bare @import("builtin") was deprecated in favour of std.builtin
<pixelherodev>
shakesoda, right thanks
<ifreund>
TheLemonMan: all clear, I'll assume there was good reasoning behind that
<pixelherodev>
Probably to limit the number of imports?
<pixelherodev>
That is, you shouldn't be accessing it directly anyways
<pixelherodev>
It's tightly linked to stdlib anyways
<shakesoda>
i feel like it makes more sense in std
<TheLemonMan>
the raw "builtin" struct is the one generated by the compiler, the std one contains the needed type defintions to complement it
cren has joined #zig
<andrewrk>
it's planned to have a "builtin" (maybe renamed) package as a compiler-provided dependency of every package, and it can have different values
<andrewrk>
for example @import("builtin").mode might be .ReleaseFast for your "blake3" package and "std" package but .Debug for your main application
<andrewrk>
there are a few things that need to be solved there since code currently uses std.debug.runtime_safety which would deal with this incorrectly
<pixelherodev>
Isn't that overkill?
<pixelherodev>
Ah wait, that's just an example
<mikdusan>
that's basically like an additional IrExecutable, handing it a custom builtin to bootstrap with. of course we don't want it to recurse
<pixelherodev>
I was thinking that if @optimizeFor can work on a per-module basis, that would be sufficient anyways
<GreaseMonkey>
> [06:22:07] <pixelherodev> Run *anything* that uses a GPU through valgrind <-- LIBGL_ALWAYS_SOFTWARE=yes might fix some of that
<shakesoda>
although that looks like it has improved a fair bit, judging by mesamatrix
<GreaseMonkey>
software's been at 3.3 for a few years now
<shakesoda>
yeah, and 3.3 is pretty retro now
<GreaseMonkey>
it scares me to see that word attached to anything to do with any GL 3.x version
<mikdusan>
I think `@` should just be _the_ builtin namespace and @import("builtin") just be @bits with @bits.mode, @bits.valgrind_support, ... and other sub-namespaces as needed; makes for a new home to std.debug.runtime_safety
<shakesoda>
compute hardware is ubiquitous these days and it's totally reasonable to rely on
<shakesoda>
which puts the cutoff for modern at GL 4.3 and ES 3.1
<shakesoda>
having compute available also fundamentally changes how you use the graphics api
<fengb>
That’s a pretty stylish G
Nypsie has quit [Quit: WeeChat 2.8]
<pixelherodev>
3.3 should *not* be "retro" IMO
reductum has joined #zig
st4ll11 has quit [Ping timeout: 260 seconds]
reductum has quit [Quit: WeeChat 2.8]
<sanaris>
my ideal computer language would be LaTeX sadly it doesn't compile into anything outside of documents
<sanaris>
It is so easy to screw up in mathematical languages, so I think the more dangerous language is, the better
<shakesoda>
pixelherodev: it is though
<shakesoda>
i mean, retro might be a bit far, but it doesn't reflect the way gpus are anymore.
<sanaris>
I was learning Haskell and SL and neither of those was any close to C, simply because they either automatic or dynamic or just screw up with cost of operations
<shakesoda>
consider also how old opengl 3.3 actually is (over a decade!)
<fengb>
It's a false dichotomy between dangerous and Haskell
<fengb>
Haskell just doesn't map to low level hardware well. But we can have something that's both low-level and safer
<sanaris>
Also the thing with Haskell folks is they give you same simplicit examples which C++ folks were giving to C folks decade ago
<shakesoda>
hardware capable of compute shaders has been shipping since then, too (slightly earlier)
<companion_cube>
fengb: aka rust
<fengb>
e.g. C pointers are "safer" than raw int accesses. But everyone agrees that's better than just making everying an int
<sanaris>
Also somehow I see everywhere people blaming NULL value for something, which I don't understand what is has in common with language itself.
<fengb>
Because it's easy to have a language construct to guard against nulls
<fengb>
Zig has it. It works really well
<fengb>
I'm pretty sure when writing Zig, I haven't had a hanging null reference yet. Whereas in C, I can't confidently say I've ever handled it correctly
st4ll11 has joined #zig
<companion_cube>
sanaris: null being an invalid but possible value of most types, is a source of bugs
<shakesoda>
fengb: i've run into it a few times in zig... but not in pure zig code that isn't abusing ptrcasts
<shakesoda>
the rules are of course totally off once you're doing that, or you're haphazardly throwing around pointers from c land
<sanaris>
I am thinking of absolutely dangerous language, where bugs could be created with single typo, but giving infinite possibilities (and not being gold-language ofc)
<sanaris>
golf*
<sanaris>
Also I was thinking how much languages today are using non-alphabetic characters, it got to insane point. In the early ages people were blaming Lisp for being too reliant on )(
<shakesoda>
perhaps terra language is interesting here
<sanaris>
By just comparing how fast I can type, casual words are much faster then all special characters combinations used by languages
foobles has quit [Remote host closed the connection]
cren has quit [Remote host closed the connection]
<fengb>
Do you recommend Pascal's begin/end blocks? :P
<sanaris>
nah too much characters, better stick to bs/be :)
<mikdusan>
ok {}
<fengb>
if / fi is the best
<companion_cube>
if / end if;!
<fengb>
esac
<sanaris>
still 'end' looks cool, so it may end them all
<sanaris>
I miss 'goto' it has something special inside
<sanaris>
the spice melange
<shakesoda>
i rather like lua's approach to all this
<shakesoda>
and almost everything else
<ikskuh>
shakesoda: everything ends!
joey152 has joined #zig
<sammich>
just curious, i saw someone say zig will reorder struct fields, is it possible to tell it to not? I've worked on stuff before that required particular struct orders
<sammich>
i guess: s/will/can
<fengb>
If you need explicit control of memory, you should use extern struct or packed struct
<sammich>
Oh interesting, thank you!
<alexnask>
If you just need to use the known offset to get a pointer to the struct from a pointer to a field you can use @fieldParentPtr
<sanaris>
Laguages today are using too little from ideas of contexts and environments. For example I thing using Goto should switch environments correctly, not simply drop everything or limiting Goto to single block
<TheLemonMan>
so..continuations?
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
wootehfoot has quit [Read error: Connection reset by peer]
foobles has joined #zig
<yrashk>
wouldn't it be cool to have custom-packed structs? like struct packed(function-that-gets-struct-ast) { ... }
<ikskuh>
yrashk: this sounds horrible, how should the compiler generate loads/stores for this?
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
wootehfoot has joined #zig
ur5us has joined #zig
<Snektron>
It would be cool as you could implement different abi in userland
<Snektron>
But the added language complexity is probably not worth it
klltkr_ has joined #zig
<pixelherodev>
Heh, Zig with Luaesque block syntax
<pixelherodev>
That would certainly be interesting
<foobles>
do/then .. end?
dimenus has joined #zig
wootehfoot has quit [Ping timeout: 260 seconds]
Kingsquee has joined #zig
<dimenus>
This is #offtopic, but do any of you guys use a 2k/4k monitor on linux?
<pixelherodev>
...2k?
<pixelherodev>
What's that in, you know
<pixelherodev>
actual numbers?
<pixelherodev>
and not marketing BS?
<fengb>
AKA 1080p 🙃
<nephele>
ah "full-hdmi"
<nephele>
hd*
<dimenus>
2560x1440 or 3840x2160
<dimenus>
:)
<dimenus>
I'm running HiDPI now and it's........fun on X
<pixelherodev>
Try Wayland?
<pixelherodev>
wlroots-based compositors support HiDPI AFAIK
<dimenus>
sway is almost perfect, kwin is buggy
<pixelherodev>
Neither of those facts shocks me :P
<nephele>
does zig plan to implement dtls/tls itself?
dimenus has quit [Remote host closed the connection]
dddddd has quit [Ping timeout: 260 seconds]
chivay_ has joined #zig
<pixelherodev>
... asBytes exists...
* pixelherodev
facepalms
<pixelherodev>
That makes life *so much easier*
chivay has quit [Ping timeout: 265 seconds]
mattmurr has joined #zig
_Vi has quit [Ping timeout: 244 seconds]
<Kingsquee>
If a target doesn't have simd, @Vector will be converted to scalar ops, right?
shakesoda has quit [Quit: Connection closed for inactivity]
<pilnik_>
the zig lang repo, i didn't build zig though just installed the binaries
<fengb>
Running test for any file in lib/std should work
<fengb>
You’ll need to use override-lib-dir `zig test --override-lib-dir lib lib/std/file.zig`
<pilnik_>
still get "error: import of file outside package path"
mattmurr has quit [Ping timeout: 265 seconds]
mattmurr has joined #zig
<pilnik_>
oh right maybe that's because i'm trying for a file in a subdirectory, files in /lib/std do work now
<pilnik_>
will keep looking into it thanks
<fengb>
The ones in the nested directory are usually referenced via a top file: std/fmt/*.zig are pulled in via std/fmt.zig
<pilnik_>
ah gotcha
<pilnik_>
that worked :)
<foobles>
hey, i was just talking to someone and he realized an issue in the C++ codebase
<foobles>
all the constexpr ir_inst_id functions are marked as constexpr, but since they all require pointers to be called, it will NEVER be evaulated at compile time