<Snektron>
Hadn't shared this yet here: a first preview of rendering. Thats a quarter sphere made up of 256³ voxels
<DarkUranium>
pixelherodev, ^ one idea ... raytracer.
<DarkUranium>
(you know what for)
<Snektron>
It's extremely slow (about 1 fps or so on my laptop) as i'm not taking advantage of the acceleration structure yet, but i have thought of a plan:
<pixelherodev>
Hmm... not a bad idea, but it's outside my field of expertise, sorry
<Snektron>
Currently the voxels are stored in a generic type of octree, where each node has N³ children with a pointer and a color
<Snektron>
Stored in a single shader storage buffer
<Snektron>
Instead, i'll use a series of 3D textures: One type for internal nodes, which consist of just an offset into the next level, and another type for leaf nodes, which just contain colors
<Snektron>
I'll make every level individually configurable for size, as well as make the height configurable. Hopefully that structure works better. Also 3D textures for 3D cache
<Snektron>
<DarkUranium "(you know what for)"> I don't, what about it?
<DarkUranium>
Snektron, pixelherodev does :P
<DarkUranium>
(it's for that repl.it language jam, we're deciding on a "sample project")
<Snektron>
oh
<pixelherodev>
I have a bunch more free time now, and it looked interesting, so I figured I'd help out on a second compiler :P
<alexnask>
Ah cool
<pixelherodev>
And KnightOS again. And Zany80 again (a project I started four years ago and mostly abandoned half a year ago)
<pixelherodev>
One or two other things too :P
<pixelherodev>
Plus I'm ramping up time spent on Zig :D
<Snektron>
Trying to make some money i see?
<pixelherodev>
I wish :(
<Snektron>
with a $10K prize
<pixelherodev>
Ah, you mean repl.it
<pixelherodev>
That would honestly be awesome
<pixelherodev>
But I consider that a bonus
<DarkUranium>
I don't have high hopes for that reward, the project's too conservative, I think. But hey, it's an excuse to do this :D
<pixelherodev>
^
<Snektron>
>During the jam, we ask all participants to code and submit their projects on Repl.it
<Snektron>
ouch
<pixelherodev>
Yeah that's the one downside
<DarkUranium>
I suspect it's fine if we code offline and just do daily uploads, though.
<pixelherodev>
...
* pixelherodev
adds that to the email
<DarkUranium>
Someone should make an "open collaboration protocol".
<alexnask>
DarkUranium, Are you guys building the embedded language you were talking about or is that another project?
<DarkUranium>
alexnask, we are :)
<Snektron>
<DarkUranium "Someone should make an "open col"> Thats called git
<DarkUranium>
Snektron, I mean live collab (which is sort of repl.it's shtick)
<DarkUranium>
I.e. operational transformation or such.
<Snektron>
oh, right
<DarkUranium>
Of course, the problem is that you have 5 million flavours there. Of OT, of CRDTs, of DS ...
marnix has quit [Ping timeout: 260 seconds]
stalli has quit [Ping timeout: 240 seconds]
stalli has joined #zig
stalli has quit [Ping timeout: 240 seconds]
stalli has joined #zig
<Snektron>
So whoever else uses matrix and is in here, theres a Zig matrix room now. I made a group to group the irc and matrix rooms together: https://matrix.to/#/+ziglang:matrix.org
dermetfan has joined #zig
Kingsquee has quit [Read error: Connection reset by peer]
dermetfan has quit [Ping timeout: 272 seconds]
alexnask has quit [Quit: Leaving]
craigo has quit [Ping timeout: 240 seconds]
<pixelherodev>
Anyone want to proofread the "How to backend" post?
alexnask[m] has joined #zig
<DarkUranium>
pixelherodev, go to sleep! :P
<pixelherodev>
I will!
<pixelherodev>
:P
<pixelherodev>
I just finished the second draft
<pixelherodev>
Now I'm sleep
<pixelherodev>
If anyone does want to, ping me for link
<DarkUranium>
Maybe later (but you'll be awake by then anyways, so :P)
Nypsie[m] has joined #zig
Nypsie[m] has quit [Quit: authenticating]
Nypsie[m] has joined #zig
eleanor-nb has joined #zig
<alexnask[m]>
👋 eleanor-nb
<eleanor-nb>
Heyo
<eleanor-nb>
pixelherodev I will proofread
<ikskuh>
alexnask[m]: here via matrix? :O
<ikskuh>
and hey eleanor-nb!
<Snektron>
Matrix is the lazy solution to irc
<ikskuh>
i won't use matrix until they make a push-based backend
<Nypsie[m]>
Works surprisingly well, the Matrix bridge that is
<ikskuh>
still, matrix is based on HTTPS polling
<ikskuh>
which is horrible
<Nypsie[m]>
Interesting approach, considering the (better) alternatives we have.
<ikskuh>
yep
marnix has joined #zig
Nypsie has quit [Quit: WeeChat 2.9]
eleanor-nb has quit [Remote host closed the connection]
josias has joined #zig
<gruebite>
hmm, can i cast a known length (at runtime) C pointer to a slice? basically [*c][*c]const u8 -> [n][]const u8?
dermetfan has joined #zig
<ikskuh>
yeah, slice it
<ikskuh>
var ptr: [*c][*c]const u8 = …;
ask6155 has joined #zig
<ask6155>
hello!
<ikskuh>
var slice : [][*]const u8 = ptr[0..len];
<ikskuh>
hey ask6155
<ask6155>
hello
<Nypsie[m]>
Hello
<ask6155>
It is better to use bindings of others or make your own considering the language is so new
<ifreund>
ask6155: well, it depends. I just use @cImport() directly cause I haven't invested the time to write good bindings yet
dddddd_ has joined #zig
dddddd has quit [Ping timeout: 264 seconds]
dddddd_ is now known as dddddd
<ask6155>
I thought you can cImport and then write your 'glue' code on top of that
<alexnask[m]>
Yeah usually to pass slices instead of ptr lengths and use error handling I guess
<gruebite>
yeah
<gruebite>
ptr[0..len] would be [][*c]const u8
xackus_ has joined #zig
<ifreund>
ask6155: yes you totally can, I just have put in the time to do so as it hasn't seemed like it would be "worth it" yet
<gruebite>
i'm currently writing a tile engine on top of glfw/libepoxy
<ifreund>
gruebite: you can also create slices by manually setting the .ptr and .len fields, they're just like special structs
<andrewrk>
fengb, if it's not a pressing issue, I can tell you that will Just Work in stage2, including when using the optional LLVM backend, because we can handle the operations manually we know llvm won't handle
<fengb>
Hmm okay
<fengb>
I'll copy it out into my own project then. Thanks
<andrewrk>
llvm/clang's goals are more like, "let's redo gcc but with a different license" and zig's goals are more like, "let's challenge some of the assumptions we have about low level systems programming, and come up with a better way for it to work"
<fengb>
Rocking the boat
<andrewrk>
in stage2 when llvm support is added, it will be pulling less weight than it is in stage1
<companion_cube>
"redo gcc but in a modular way", too
<andrewrk>
yeah, fair
<andrewrk>
although if you're referring to llvm ir, doesn't gcc have gimple?
<companion_cube>
well also the fact it's a collection of libraries :)
<companion_cube>
(I don't know if gimple was really a public thing when llvm got started)
<andrewrk>
gotcha
<companion_cube>
really, what llvm gave us is a big crop of new languages (zig, rust, crystal, julia, etc.), and I find it quite exciting; of course it's also good to not be totally reliant on it
<andrewrk>
agreed
<fengb>
LLVM split because gcc wouldn't have a stable IR
<andrewrk>
from zig's perspective, llvm was training wheels :)
<fengb>
It was originally a backend plugin to gcc
<alexnask[m]>
really? til
<companion_cube>
it might still be the high-perf backend, andrewrk, right?
<andrewrk>
yeah sure
<companion_cube>
you're not going to rewrite all the optims of llvm :D
<andrewrk>
I do foresee pure zig release builds having a couple optimization passes (think 80% of the perf for 20% of the work) and I foresee the compilation speed and less bloated compiler being so attractive that many people prefer it
<andrewrk>
but the short-to-medium term plan is llvm backend for release builds, yes
<companion_cube>
release-fast using llvm, release-{safe,small} using internal backend ;)
<andrewrk>
even with llvm backend there's a reason to do this, which is that zig's optimization passes would be async/await/suspend/resume aware
<leeward>
LLVM was offered as a path forward for GCC, and Stallman opposed it on the grounds that it was too easy to make proprietary extensions with a well architected plugin system.
<ifreund>
heh
<alexnask[m]>
Im going to start working on PE support for stage2 (Michel Larouche had started it but dropped it, he has made his code public though)
<andrewrk>
the existence of gcc is important. I would be really concerned if it died and left us with only llvm
<ifreund>
aye
<andrewrk>
alexnask[m], exciting!
<pixelherodev>
I agree here
<pixelherodev>
I actually think Stallman made the right decision there
<pixelherodev>
even if I disagree with his reasoning :P
<companion_cube>
wait, they wanted to *replace* gcc with llvm?
<leeward>
The world is better off because LLVM forced GCC to mature, but it would be even more better if they had accepted the patches.
<companion_cube>
I thought it's more that llvm became popular because gcc refused to be modular
<andrewrk>
alexnask[m], are you planning to try to solve incremental compilation?
<fengb>
Who knows at this point. Apple wouldn't have tossed millions of dollars at a GPL compiler chain
<leeward>
Apple used GCC before they used LLVM.
<fengb>
But they didn't really invest in it
<fengb>
Clang was an Apple project
<alexnask[m]>
andrewrk: Ideally yes
<andrewrk>
awesome
<leeward>
I don't think Apple was ever opposed to the GPL for their tool chain; they're just very pragmatic.
<fengb>
They're anti GPLv3
<companion_cube>
(oh, forgot swift in my list, duh)
<BaroqueLarouche>
PS3 SDK used GCC and it stopped updating it when it switched to GPLv3
<leeward>
fengb: Who isn't?
<pixelherodev>
fengb: I don't think that's true
<pixelherodev>
I think that if LLVM wasn't around, and GCC had been willing to work with them, Apple wouldn't have cared about the license
<andrewrk>
alexnask[m], for ELF, the file format is flexible enough that I was able to use it directly for incremental compilation. if that works out for PE too, that's great. but if we need to store external metadata to make incremental compilation work, that's ok too
<fengb>
It's hard to say now
<pixelherodev>
Of course
<pixelherodev>
It's all very hypothetical
<pixelherodev>
And I'm not wasting today of all days on those
<andrewrk>
alexnask[m], right now, there is external metadata related to incremental compilation that is kept in memory. the plan for making it persist on disk would be to serialize and deserialize that state that is currently in-memory-only. but I think it is ok to make it in-memory-only for now. it should be fairly straightforward to add serialization/deserialization support later
<andrewrk>
I do think the in-memory support is nice though. So far it's pretty darn efficient
<andrewrk>
fast too. it takes 30 milliseconds on my machine to run `./zig build test-stage2`
<pixelherodev>
What?!
<pixelherodev>
From start to finish?
<pixelherodev>
Or after running it the first time?
<andrewrk>
when the test harness is already built. so it measures a debug build of the self-hosted compiler, running every single stage2 test case (including compare_output tests where it has to run the program)
<alexnask[m]>
wow, thats pretty insane
<andrewrk>
I've been adding new test cases as incremental updates to single functions :D
marnix has quit [Ping timeout: 256 seconds]
<leeward>
fengb: Geoff Keating is one counterexample regarding Apple's willingness to throw money at GCC.
<pixelherodev>
Gotcha
dermetfan has joined #zig
<gruebite>
more idiomatic to return a struct or to set pointer parameters?
marnix has joined #zig
<ikskuh>
return a struct
<pixelherodev>
Probably the former?
<pixelherodev>
Yeah
<ikskuh>
as we have optionals, it's convenient to use when the return value is not always there
<gruebite>
cool, my intuition isn't off haha
<gruebite>
yeah
<gruebite>
i always have the issue of too many vectors across code bases
<gruebite>
i almost feel linear algebra should be standard to prevent every application rewriting their own, and then writing code to convert between them
<gruebite>
complex numbers are often part of a standard library
<protheory8-new-m>
Hi, is there a workaround again std.mem.Allocator.resizeFn 'resize in place' guarantee? I kinda want to use realloc there.
<pixelherodev>
protheory8-new-m: no
<pixelherodev>
You can choose to not use Allocator if you want to
<leeward>
You can use realloc directly.
<pixelherodev>
If you're explicitly requiring realloc, might as well use allocation directly
<pixelherodev>
Yeah
<protheory8-new-m>
So what is the limit of c_allocator when reallocating?
<protheory8-new-m>
I allocate slice of 4 u8 using allocator.alloc, what is the maximum I can reallocate to?
<alexnask[m]>
c_allocator uses malloc_size on platforms its available on
<alexnask[m]>
(or malloc_usable_size)
stripedpajamas has quit [Quit: sleeping...]
<protheory8-new-m>
Yeah, that's what I did as well IIRC
<protheory8-new-m>
Thanks for help
nikita` has quit [Quit: leaving]
Akuli has joined #zig
stripedpajamas has joined #zig
<gruebite>
i cannot self reference enums? like: enum { a, b, last = b }
<pixelherodev>
nope
<pixelherodev>
extern enums I think can
marnix has quit [Ping timeout: 260 seconds]
riba has joined #zig
dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
<gruebite>
oo, but can do const members on an enum
<pixelherodev>
I might take today off and finish the PR and article tomorrow
<gruebite>
:)
<Nypsie[m]>
pixelherodev: Eleanor wanted to review the article btw. (Incase you missed it)
<pixelherodev>
I saw
<Nypsie[m]>
:)
<pixelherodev>
I just need to make a few tweaks and them i'm linking it to them
riba has quit [Quit: Lost terminal]
<protheory8-new-m>
So I think I made a Jemalloc wrapper for `std.mem.Allocator`, not sure if it works correctly though.
<andrewrk>
I'm not aware of any other compiler that has done this before
<Snektron>
maybe you should apply for the repl.it think, andrewrk
<Snektron>
easy $10K
<Snektron>
err, thing, the design-a-language hackathon
<Nypsie[m]>
They ask you to keep working on it afterwards for 3months, would be a waste of Andrew's precious time I assume :P
nycex has quit [Ping timeout: 240 seconds]
nycex has joined #zig
<pixelherodev>
lol
<pixelherodev>
Please don't, that'd be more competition for me! ;)
<pixelherodev>
And I don't think I'd win against you lol
<pixelherodev>
andrewrk: you've forced my hand :(
<pixelherodev>
Going to finish the PR today
<pixelherodev>
So. Much. Rebasing.
<pixelherodev>
Ugh
<gruebite>
all your rebase?
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
<andrewrk>
Snektron, I'm not really interested in designing languages, believe it or not. Zig is a means to an end for me
<andrewrk>
the end being, of course, higher quality software
<Snektron>
Turned out youre good at it though
<Nypsie[m]>
Maybe an odd question, but do you still work on side projects (which are not Zig but written in Zig), like you mentioned in your blog once?
<andrewrk>
I want to, but I'm feeling a lot of pressure to get stage2 done. I think I'll start doing that again once we can ship stage2
<pixelherodev>
:(
<pixelherodev>
I love the rate of progress of stage2, but that seems like a price a bit too high to pay to me
<andrewrk>
I think if you took my ELF16 suggestion you wouldn't have any conflicts with the latest commits
<Nypsie[m]>
I see, makes sense. Thanks :)
<pixelherodev>
andrewrk: I'm working on it!
<pixelherodev>
:P
<pixelherodev>
Ah wait
<pixelherodev>
No, yeah, I'm not going to do that, there's no point
<pixelherodev>
I'll just deal with this until it's done
<ifreund>
yeah make sure you don't burn out on stage2, we can be patient
<pixelherodev>
ELF16 really *is* just ELF32 with 16-bit pointers
<Snektron>
> I want to, but I'm feeling a lot of pressure to get stage2 done.
<pixelherodev>
Having it be a separate linker backend doesn't make sense
<pixelherodev>
Most of the .p16 => branches go with p32 anyways
<Snektron>
You also deserve some time off once in a while though
<pixelherodev>
for sure
<pixelherodev>
We're not heartless here, Andrew! We can wait!
<andrewrk>
yeah don't worry I'm taking care of myself
<andrewrk>
it's self-imposed pressure
<pixelherodev>
One might even go as far as to call it *self-hosted* pressure
<pixelherodev>
;)
<ifreund>
gah :P
<Snektron>
nice
<fengb>
Programmers tend to have a lot of pent up self-imposed pressure
<Snektron>
I've worked on that actually. I used to drop every project after a week or so, now i can commit myself to actually finishing something once in a while
<shakesoda>
fengb: artists, too
<leeward>
Writing software is the closest one can get to being a wizard these days. Wizards are always workaholics.
<shakesoda>
fengb: woe is the cursed individual who is both
<rom1504>
what are stage1 and stage2 for zig ?
<pixelherodev>
stage1 is the compiler you've probably used, and is written in C++
<pixelherodev>
Stage2 is the compiler that's being written within Zig to compile ZIg
<pixelherodev>
Which is why it's also called self-hosted
<pixelherodev>
Since we can compile it using itself
<fengb>
Stage 1 is what we have right now: Zig compiler written in C++
<ikskuh>
fengb: lul
<leeward>
fengb: Exactly, except Lisp no longer has a monopoly.
<rom1504>
ah I see, makes sense :)
<Snektron>
leeward: yeah theres c++ templates now, too
<leeward>
Snektron: I guess voldemort is a wizard too.
<rom1504>
does zig stage2 use llvm ?
<Snektron>
Not yet, and possibly also will not
<pixelherodev>
Hopefully will not
<pixelherodev>
It'll be optional at worst though, so yay
<ikskuh>
i hope it will (be optional)
<ikskuh>
i need those size optimizations :D
<andrewrk>
pixelherodev, I think you're trying to do too much in 1 PR still
<ikskuh>
^=
<rom1504>
okay so it's really about rebuilding the whole thing, interesting
<pixelherodev>
andrewrk: sure, but the ELF stuff is fine
<pixelherodev>
ANd it's better than the SPU II one at least :P
<ikskuh>
pixelherodev: make more and smaller PRs that depend on each other
<andrewrk>
rom1504, yeah rebuilding the whole thing, with lessons learned, and making a big effort on performance and resource utilization
<pixelherodev>
I'm working on it
<pixelherodev>
My commit hygiene can use a bit of work too
<ikskuh>
mine as well
<ikskuh>
i just did "git add .; git commit -m "Snapshot"; "
<andrewrk>
me too tbh
<fengb>
Be like kristate: single commit per PR
<ifreund>
git add -p is your friend
<ikskuh>
Semantic Analysis [46/33081]
<ikskuh>
what did i do?!
<andrewrk>
stage1 is pretty inefficient with std.fmt.format
Akuli has quit [Quit: Leaving]
<pixelherodev>
I'm like the anti-kristate
<ikskuh>
fuck. i now have 32k compiler errors
<pixelherodev>
I just wiped my place on the contributor "leaderboard" :P
<pixelherodev>
I went from ~12 to not even on the list lol
<andrewrk>
ikskuh, oh yeah I've been meaning to implement the deduplication for that. it should only emit 1 per AST node
<ikskuh>
:D
<ikskuh>
only in stage 2 please :D
<andrewrk>
ikskuh, pixelherodev, is ELF16 documented somewhere?
<ikskuh>
i think pixelherodev made that up :D
<andrewrk>
hmmmmmmmm
<ikskuh>
let's see if my code compiles or if i got another 32k errors :D
<andrewrk>
why can't ELF32 be used for SPU Mark II
blinghound has joined #zig
<ikskuh>
i don't see the problem
<andrewrk>
ok that's for sure the right thing to do then
<ikskuh>
let me check what avr uses
<andrewrk>
it's gotta be elf32
ur5us has joined #zig
<ikskuh>
blink1.elf: ELF 32-bit LSB executable, Atmel AVR 8-bit, version 1 (SYSV), statically linked, with debug_info, not stripped
<ikskuh>
ye
<andrewrk>
pixelherodev, you mad lad! use ELF32 you knuckle head!
<ikskuh>
+1
<andrewrk>
he's over here like "I have to keep rebasing my ELF16 code because Andrew keeps breaking it with ELF32 improvements" 🤣 🤣
<ikskuh>
andrewrk: I'm crazy atm :D
<ikskuh>
"rewriting" my spu mk 2 emulator with every instruction comptime-unrolled
<ikskuh>
so instead of doing decoding, i just do try jumptable[opcode]();
<ikskuh>
:D
<shakesoda>
sounds simpler/more legible
<shakesoda>
certainly looks it
<ikskuh>
looks like it's finally compiling :D
<andrewrk>
ikskuh, it's the kind of thing that makes me feel pressure to get stage2 done, because it's a perfect fit for the zig language, but stage1 looks like a clown car trying to compile it
<ikskuh>
but i accept any waiting time atm
<ikskuh>
also, i found like 100 stage 1 bugs right now :D
<ikskuh>
switch() {} can return different types :D
<Sahnvour>
stage2 will possibly not use LLVM ? what's planned for release builds ? (sorry i'm outdated)
<alexnask[m]>
ikskuh: I think stage1 doesnt do peer type resolution (at least in some circumstances)
<andrewrk>
llvm will be an optional dependency
<ikskuh>
aaaah, too much evaluation :D
<ikskuh>
for some instructions ".div => input0 / input1," this generates a division by zero
<ikskuh>
yes, compiler! you are right! :D
<ikskuh>
dang :D
<alexnask[m]>
For example if you have an if else that reutrns an enum value or an enum literal, the type will not be resolved to the enum if the else branch is taken
<alexnask[m]>
(I remember this because it was the source of a std.fmt bug)
<Snektron>
invoking ub again, ikskuh?
<ikskuh>
kinda? :D
<ikskuh>
i just accepted that my emulator crashed on div by zero
<andrewrk>
alexnask[m], the result location implementation in stage2 is looking squeaky clean so far
<ikskuh>
because that'S what the CPU does anyways :D
<ikskuh>
so now the emulator core has a evaluation check
<ikskuh>
let's run that again
<pixelherodev>
andrewrk: I am using ELF32!!!
<pixelherodev>
That's literally what I'm doing!
nycex has quit [Ping timeout: 240 seconds]
<pixelherodev>
What I'm calling ELF16 is literally just ELF32 that happens to use 16-bit pointers for generated code!
<andrewrk>
I see, well I thought you were inventing a new format, which is why I didn't tell you to not introduce p16
<Snektron>
Will the result location system in stage2 also work for general expressions? Like if i write `fn a() B { var b: B = undefined; b.x = 10; b.y = 20; return b; }`
<andrewrk>
which is the source of the rebase conflicts. the p32/p64 corresponds to the ELF format not the arch ptr size
<pixelherodev>
...
* pixelherodev
facepalms
<pixelherodev>
This is what I get for not asking for clarity and for making assumptions
<ikskuh>
^=
<andrewrk>
every time I wrote one of those switch statements, I thought to myself, "Cool, there are only 32 and 64 bit elf formats, so nobody will have to touch this switch statement again."
<pixelherodev>
I'm going to finish the article and prefix it with "A lot of this depends on work that hasn't yet been merged, I suggest giving it a few days before working on this to avoid conflicts" or something
<pixelherodev>
Then I'll split the PR up into pieces and get them all done
<pixelherodev>
My goal is to get to the next round of review tonight
<leeward>
Snektron: I hope so.
ur5us has quit [Quit: Leaving]
<pixelherodev>
Ugh, I've started using nested tmux sessions fo rliterally everything
<pixelherodev>
It's the only way to *force* it to repaint
<pixelherodev>
(that took me less than ten seconds to figure out and doesn't require me poring through the manual)
<ikskuh>
thanks to unrolling the emulator, i found a lot of bugs :D
<pixelherodev>
ikskuh: mind sending that as a PR to my spu_ii branch's std.spu.interpreter? :P
<ikskuh>
haha
<pixelherodev>
No reason to duplicate work
trevarj has quit [Remote host closed the connection]
<ikskuh>
well
<ikskuh>
the backported stuff, yeah :D
<pixelherodev>
:)
<ikskuh>
not the thing i'm currently building
<pixelherodev>
For sure
<pixelherodev>
just the core architecture
<ikskuh>
that has roughly 5-10 minute compile time atm :D
<pixelherodev>
holy mother forking what
<pixelherodev>
WHY
<alexnask[m]>
for science
<ikskuh>
<alexnask[m]> for science
<ikskuh>
FOR SCIENCE!
<Sahnvour>
at last a language that compiles faster than C++ !
<pixelherodev>
haha
<ikskuh>
LLVM Emit Output...
<ikskuh>
:O
<Sahnvour>
ikskuh: by unrolling the emulator, do you mean the program it's running is embedded at comptime ?
<ikskuh>
no
<ikskuh>
unroll all instruction emulations into branchless versions
<andrewrk>
are we going to find out how this affects perf?
<ikskuh>
andrewrk: yeah, true
<ikskuh>
i hope so!
<pixelherodev>
We'd better find out!
<pixelherodev>
:)
<ikskuh>
in theory, 1 branch is waaaay better than a lot :
<ikskuh>
:D
<pixelherodev>
Why is this an exceptionally better use case for Zig than anything else?
<pixelherodev>
ikskuh: especially with branch prediction!
<Sahnvour>
ah, if I get this right you're generating the functions evaluating opcodes ?
<pixelherodev>
Ah right, are you going to use computed gotos?
<alexnask[m]>
comptime everything
<ikskuh>
Sahnvour: yep
<Sahnvour>
cool
<andrewrk>
pixelherodev, assuming (incorrectly) that the compiler handled it reasonably, the cost of this experiment is extremely low in zig, compared to say, c++
<pixelherodev>
Gotcha
<andrewrk>
cost of the experiment in terms of developer time
<pixelherodev>
ikskuh: computed gotos should help even more if there's a good way to Zig them
<andrewrk>
and maintenance of the codebase
<ikskuh>
hehe
<ikskuh>
pixelherodev: we don't need computed goto
<pixelherodev>
Why not?
<ikskuh>
we have guaranteed tail calls
<pixelherodev>
...so?
<ikskuh>
which is the same
<ikskuh>
but with arguments :D
<pixelherodev>
Ah right, that's a unconditional jump
<pixelherodev>
Hmm
<pixelherodev>
I think computed goto might actually help perf anyways
<alexnask[m]>
Yeah this blew my mind too when xq showed me an example :P
<pixelherodev>
Since it ties branch prediction to the previous instruction, no?
<pixelherodev>
Hmm, this might do that too
<pixelherodev>
Not 100% on the details of how tail calls would affect this TBH
<alexnask[m]>
Iirc in a small experiment with the tail calls vs the computed goto the assembly was exactly the same (maybe some really minor deviations)
<pixelherodev>
Cool!
<pixelherodev>
That's even better!
<ikskuh>
yeah, i think tail call was even faster :D
<pixelherodev>
"Zig: the advantages of computed gotos without the work"
<pixelherodev>
lol
<ikskuh>
yeah, zig is really well tailored for a lot of stuff
<ikskuh>
andrewrk: i really love how zig really does a good job at "better C"
<ikskuh>
type system is great, the added features are right, and the additional control flow with error checkng and optionals just makes a lot of stuff a breeze <3
<andrewrk>
<3
<pixelherodev>
Yep
<pixelherodev>
There's two or three other langs I'm keeping an eye on with the same goal
<gruebite>
seriously
<ikskuh>
pixelherodev: which are?
<alexnask[m]>
V
* pixelherodev
laughs loudly
<alexnask[m]>
(just kidding)
<gruebite>
haha
<ikskuh>
real 4m22,391s
<gruebite>
similar goals. hopefully they get there.
<pixelherodev>
ikskuh: I'm working with DarkUranium on Coyote, which is sorta like a better C for scripting instead of compiled code
<pixelherodev>
One of the others I've been asked to keep quiet about for now
<ikskuh>
okay ^^
<gruebite>
i'm looking at carp, zig, and haxe
<pixelherodev>
I love that the programming lang scene is so active now
<pixelherodev>
I don't like Rust as a language, but I love what it's accomplished
<alexnask[m]>
Ive heard of carp, I think they were considering using zig cc as a cross compiler or smth
<gruebite>
i 100% agree
<gruebite>
although when i worked on a team using rust. i enjoyed it a lot more than doing it by myself
<andrewrk>
the keep quiet one apparently has the exact opposite marketing strategy as V
<fengb>
One thing I do love is how the extra control flows fit into expressions
<fengb>
A lot of languages make stuff like "try" or even "return" into statements and it interferes with the code structure
<gruebite>
i love anonymous structs
<fengb>
Whereas Zig lets me do silly things like `orelse return error`
<alexnask[m]>
Yeah orelse and catch are so good
dimenus has quit [Ping timeout: 256 seconds]
<andrewrk>
I hated java's try catch the same day I learned about it
<andrewrk>
it's actively harmful to correct error handling
<ikskuh>
andrewrk: zigs error handling is really standing out, but it's hard to explain to others
<gruebite>
the error handling is absolutely painless
<ikskuh>
yeah, exactly
<fengb>
Go's explicitness with less boilerplate >_>
<Nypsie[m]>
And error traces!
<fengb>
Also slightly more explicit than Go but still
<gruebite>
that's a goodway
<pixelherodev>
More explicit than Go with none of the boilerplate
<pixelherodev>
?
<DarkUranium>
ikskuh, gruebite: maybe I should have a look at it, then.
<DarkUranium>
The error handling.
<alexnask[m]>
Yeah definitely : D
<ikskuh>
yes!
nerthus has quit [Ping timeout: 272 seconds]
<fengb>
One caveat is that stage1 stack traces are getting kinda buggy :(
<pixelherodev>
zig's error handling is the best I've ever used
<pixelherodev>
It's not even a comparison
<gruebite>
i agree
<andrewrk>
fengb, it's fixable, I think I know what you're referring to
<alexnask[m]>
Yeah the resizeFn usage of OutOfmemory made this worse too
<gruebite>
error codes and error strings combined into unique members of sets, with a bunch of support
<andrewrk>
I was thinking the function pointers of Allocator should maybe not use errors at all - that could be something the Allocator interface does
<DarkUranium>
pixelherodev, how is it handled?
<DarkUranium>
Error handling is something I haven't figured out yet for Coyote.
<fengb>
So would there be separate "canResize" and "resize" functions?
<fengb>
Or maybe returning a sentinel value
<alexnask[m]>
Maybe returning an empty slice instead of an error?
<fengb>
It currently returns a usize
<alexnask[m]>
True, derp
<fengb>
`return 0xaaaaaaaa` 🙃
<pixelherodev>
DarkUranium: look at the docs ;)
<pixelherodev>
It'll do a better job explaining than I could
<fengb>
Black voodoo
<gruebite>
part of it comes from using the error handling stuff too
<fengb>
Andrew sacrificed a goat to unlock enlightenment
<DarkUranium>
pixelherodev, it seems similar to what I had in mind for Coyote. Minus the inferrence, because there are certain issues with that.
<Sahnvour>
memeification of Zig is the key to success
<Nypsie[m]>
Look at that 3 finger technique
<fengb>
Where’s the OG cabbage
<blinghound>
there is 100% chance now that some of that clip will be in my dreams tonight
<pixelherodev>
DarkUranium: that makes sense
<pixelherodev>
A similar strategy minus inferred errors should be good for Coyote I think
<DarkUranium>
pixelherodev, basically, I was thinking I could take advantage of the fact that option types need the storage for a pointer even if they don't have one --- and I could (ab)use that for errors.
<DarkUranium>
In other words, T? could hold an error, too.
<gruebite>
none is a special type of error?
<DarkUranium>
(in a sense, `null` would then just be a "no error", then)
<DarkUranium>
gruebite, yeah. It's a bit ugly, I know, but I don't want too many "special" types.
<DarkUranium>
pixelherodev, anyways, two more operators I've been toying with: One is a ?? b (this one was actually stolen from C#)
<DarkUranium>
it means a ? a : b
<DarkUranium>
Sorry;
<DarkUranium>
a ? a! : b
<alexnask[m]>
The elvis operator :)
<DarkUranium>
And the subtly different a?:b, which is a ? a : b ... my issue is that it could be confusing to have both.
<alexnask[m]>
Ah elvis is the second one : p
<Nypsie[m]>
I believe Dart uses that as well
<pixelherodev>
I think it's fine to have both
<pixelherodev>
I'm not sure it's needed though
<DarkUranium>
Nypsie[m], Dart has a few good ideas. But also a number of bad ones.
<pixelherodev>
between the two, I'd stick with ??
<pixelherodev>
?: doesn't seem needed
<DarkUranium>
pixelherodev, it is, for non-option types ... no?
<pixelherodev>
... maybe make ?? type-dependent?
<pixelherodev>
For optional types, it's a ? a! : b
<DarkUranium>
Guess I could.
<pixelherodev>
For non-optional types, it's a ? a : b
<pixelherodev>
Should we move to #coyote if it's not taken? :)
<pixelherodev>
Neat, you made it already :)
<DarkUranium>
Long ago :P
<gruebite>
kotlin has elvis operator too
<gruebite>
i like zig's orelse
<DarkUranium>
lol
<DarkUranium>
That sounds threatening.
<pixelherodev>
Perfect!
<pixelherodev>
I like that
dimenus has joined #zig
dermetfan has quit [Ping timeout: 272 seconds]
eleanor-nb has joined #zig
eleanor-nb has quit [Remote host closed the connection]
<gruebite>
it didn't take long for me to prefer zig's multiline strings over others, haha
<DarkUranium>
gruebite, how do zig's multiline strings look like?
<gruebite>
\\line 1
<gruebite>
\\line 2
<alexnask[m]>
main advantage: no indentation weirdness
<gruebite>
yep
<DarkUranium>
Hm, I see.
<andrewrk>
it means that zig has line-independent tokenization
<andrewrk>
pick any arbitrary byte of zig source code - advance to \n, and you can correctly tokenize the source code after that
<shakesoda>
the `a ? a : b` talk reminds me of lua's `a or b` being nice because it isn't a weird special case, it's just how `or` works if a value is false-y
<shakesoda>
dunno if the same would work for zig, but it's a behavior i like a lot
<shakesoda>
and even if it would be fine for zig i don't feel this is really a pain point
<DarkUranium>
One thing I miss in C is a bottom type.
<DarkUranium>
So that I could do `return x ? x : error(...)`
lanodan has quit [Quit: WeeChat 2.8]
KKRT has quit [Quit: KKRT]
<gruebite>
i think zig's 0 sized types cover that base, yeah?